From ghc-devs at haskell.org Fri Jan 1 06:43:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 06:43:09 -0000 Subject: [GHC] #11327: GHC doesn't create dyn_o-boot files Message-ID: <045.1793d17d53b78f04bec36e5fa72e28d0@haskell.org> #11327: GHC doesn't create dyn_o-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Take any set of modules with a loop broken by an hs-boot, and run `ghc --make -dynamic-too` on it. Suppose A.hs imports B.hs, which source imports A.hs-boot; then compiling these you will get `A.{hi,o,dyn_hi,dyn_o}`, `B.{hi,o,dyn_hi,dyn_o}`, and ONLY `A.{hi- boot,o-boot,dyn_hi-boot}`: `A.dyn_o-boot` is missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 08:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 08:10:36 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields Message-ID: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Given a haskell file; {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} -- t.hs data A = A { name :: String } data B = B { name :: String } }}} and in GHCi; {{{ ghci t.hs GHCi, version 8.1.20151231: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tnum.hs, interpreted ) Ok, modules loaded: Main. *Main> ... $sel:name:A $sel:name:B ... }}} The records show up as `$sel:function:Type`, a function which you cannot refer to by name. Even if you enable `OverloadedLabels`, the `#labels` don't show up in the auto completion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 09:12:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 09:12:46 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.3ac693187427fd63689177fb6e77a29a@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"ab0d733da504fac25b98b15f1fb758d6997d0534/ghc" ab0d733d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab0d733da504fac25b98b15f1fb758d6997d0534" Update Cabal submodule, Fixes #11326 Troublesome commit in Cabal was reverted. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 09:14:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 09:14:28 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.b78fc04de2e9dfd3df9febdc227684c0@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 10:23:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 10:23:10 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.de1a3a86338f31400b38caf1ec072629@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 10:28:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 10:28:24 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.f4d59fc6d4d796a9af087022de91f465@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f3cc34568b13abb29de7b54a5f657681e9e116ca/ghc" f3cc345/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f3cc34568b13abb29de7b54a5f657681e9e116ca" Add strictness for runRW# runRW# isn't inlined until CorePrep, so it's good to expose its strictness. Moreover, if we don't we can get obscure failures in coreToStg; see Note [runRW arg] in CorePrep. This fixes Trac #11291, and makes DfltProb1 compile with -O always in order to expose it more vigorously }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 10:30:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 10:30:46 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.c376869929b3e83d91da35ab7cc9687f@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I've fixed this one. Does this fix some of the other bugs in comment:5? If not perhaps open a new ticket? Happy new year. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 10:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 10:44:41 -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.bda4718eef11135c9503fc9b3d7f0faa@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes 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 simonpj): * cc: a.serranomena@? (added) Comment: This is definitely fallout from Visible Type Application. The program in comment:3 typechecks fine without `ImpredicativeTypes` (indeed it does in Haskell 98!) and surely `ImpredicativeTypes` should be a conservative extension. But let's not invest much in "fixing" `ImpredicativeTypes` which is simply not supported at the moment. Alejandro Serrano (cc'd) is working on impredicativity right now, so I've added him to the cc list. Alejandro, what are you doing will be significantly affected by the "lazy instantiation" approach of Visible Type Application ([https://www.cis.upenn.edu/~eir/pubs.html see paper]), so you might want to look carefully. VTA is in GHC now! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:17:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:17:50 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.f8e5885783be721842f057cfd68085a4@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 wonder if this is related to #11051 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:18:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:18:09 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.5cb5aa976508f2af764620c02c07f314@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 hvr): I wonder if this is related to #11328 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:20:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:20:14 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.52b7d4d341d190a7667d588b0942b9c1@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` > is moving into `Prelude` with future GHCs. > > Throughout GHC's source there are related pretty-printing operators with > subtly different `infixr/infixl`-declarations. > > It would be desirable to unify those and possibly use `Semigroup((<>))` > instead (where `<>` represents a semigroup/monoid operation anyway) > > Otoh, existing code using `<>` assumes a different fixity > (Monoid/Semigroup have `infixr 6 <>`), so it may make sense to start by > renaming the unconventional `<>`s into something else. > > Modules affected: > > - `Outputable`: default fixity, i.e. `infixl 9` (ghc) > - `Pretty`: `infixl 6` (ghc) > - `Language.Haskell.TH.PprLib`: `infixl 6` (template-haskell) > > Related discussion: https://github.com/haskell/pretty/issues/30 New description: {{{#!box note See also Proposal/LeftAssocSemigroupOp }}} This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` is moving into `Prelude` with future GHCs. Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) Otoh, existing code using `<>` assumes a different fixity (Monoid/Semigroup have `infixr 6 <>`), so it may make sense to start by renaming the unconventional `<>`s into something else. Modules affected: - `Outputable`: default fixity, i.e. `infixl 9` (ghc) - `Pretty`: `infixl 6` (ghc) - `Language.Haskell.TH.PprLib`: `infixl 6` (template-haskell) Related discussion: https://github.com/haskell/pretty/issues/30 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:20:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:20:20 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.55dc504242471dba6622f294250c96ad@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:22:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:22:26 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.51da7e9b99437c64cf530391d131ba78@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:8 simonpj]: > I've fixed this one. I assume this is supposed to be merged to the GHC-8.0 branch as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:28:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:28:45 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.e4e2dc8635dda3c21a44a5a33404f4f4@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Merged to GHC 8.0 via ae2c4d8af8b8e2e0e310a7fbfed6bd1d6b43386b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 11:52:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 11:52:28 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc Message-ID: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST='VtaParse Vta1 Vta2' VERBOSE=2 TEST_HC=ghc-head ... =====> VtaParse(normal) 1 of 3 [0, 0, 0] =====> VtaParse(hpc) 1 of 3 [0, 0, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): dsExpr:HsTypeOut Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for VtaParse(hpc) =====> VtaParse(optasm) 1 of 3 [0, 1, 0] =====> Vta1(normal) 2 of 3 [0, 1, 0] =====> Vta1(hpc) 2 of 3 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): dsExpr:HsTypeOut Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for Vta1(hpc) =====> Vta1(optasm) 2 of 3 [0, 2, 0] =====> Vta2(normal) 3 of 3 [0, 2, 0] =====> Vta2(hpc) 3 of 3 [0, 2, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): dsExpr:HsTypeOut Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for Vta2(hpc) =====> Vta2(optasm) 3 of 3 [0, 3, 0] Unexpected results from: TEST="Vta1 Vta2 VtaParse" }}} Tests added in commit 2db18b8135335da2da9918b722699df684097be9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 12:17:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 12:17:26 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) Message-ID: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST=dynamic-paper VERBOSE=2 TEST_HC=ghc-head ... =====> dynamic-paper(normal) 1 of 1 [0, 0, 0] =====> dynamic-paper(hpc) 1 of 1 [0, 0, 0] ... Compile failed (status 256) errors were: *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** : warning: In a case alternative: (TypeRepX k_s7Ec :: *, a_s7Ed :: k_a5px, tr2_s7Ee :: TypeRep a_s7Ed) @ k_a5px is out of scope *** Offending Program *** ... : error: Compilation had errors *** unexpected failure for dynamic-paper(hpc) =====> dynamic-paper(optasm) 1 of 1 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone delta1 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 203160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(optasm) Unexpected results from: TEST="dynamic-paper" }}} This test was added in commit 52da6bdc17bb491d6d2f462b3680eb44b9be92e5: {{{ Author: Richard Eisenberg Date: Sat Dec 26 09:11:33 2015 -0500 Have mkCastTy look more closely for reflexivity. This may have performance implications. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 12:23:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 12:23:40 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack Message-ID: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST=tc198 TEST_HC=ghc-head VERBOSE=2 =====> tc198(normal) 1 of 1 [0, 0, 0] =====> tc198(hpc) 1 of 1 [0, 0, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): lookupVers2 GHC.Stack.Types CallStack Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for tc198(hpc) =====> tc198(optasm) 1 of 1 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): lookupVers2 GHC.Stack.Types CallStack Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for tc198(optasm) Unexpected results from: TEST="tc198" }}} Test was added in 2005. Seems like a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 12:29:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 12:29:04 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.eb90e878c3c31d5eb720f2e9e895c48d@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: #11330 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => * related: => #11330 Comment: Actually,`T11248` fails with core lint errors for WAY=optasm and WAY=hpc with HEAD (8.1.20151231): {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** : warning: [in body of lambda with binder eta_B1 :: CT r_a1JX (FLCM r_a1JX t_a1KA)] No alternatives for a case scrutinee in head-normal form: lvl_s1UO @ s_a1JY @ r_a1JX @ t_a1KA @~ (cobox_a1KB :: FMul (FGCD r_a1JX s_a1JY) (FDiv (FLCM r_a1JX t_a1KA) r_a1JX) ~# t_a1KA) @~ (cobox_a1KC :: FGCD r_a1JX t_a1KA ~# FGCD r_a1JX s_a1JY) @ s'_a1K1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 14:27:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 14:27:18 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.ab014a970effe3bc71a7aa175e92b6cc@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): * owner: => gridaphobe Comment: Thanks, I'm out of town this week but will investigate when I get back! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 15:43:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 15:43:36 -0000 Subject: [GHC] #11320: Various API Annotations fixes In-Reply-To: <044.2d9c92400b05655f034c6fbce09bec02@haskell.org> References: <044.2d9c92400b05655f034c6fbce09bec02@haskell.org> Message-ID: <059.b695de0d6ef1fbf8e9753fde9ba8293e@haskell.org> #11320: Various API Annotations fixes -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: | ApiAnnotations 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): * status: merge => closed * version: 8.1 => * resolution: => fixed Comment: Merged via b24fcb5e0d1594cc296845931fe8daad34e13f7e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 18:33:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 18:33:51 -0000 Subject: [GHC] #11321: API Annotations: AnnTilde missing In-Reply-To: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> References: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> Message-ID: <059.74a4067f2f5f0ed35160b915192f8e64@haskell.org> #11321: API Annotations: AnnTilde missing -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | ApiAnnotations 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 Alan Zimmerman ): In [changeset:"0b8dc7d4d5b26e184a7698e22f9fe7d8ee3c90d4/ghc" 0b8dc7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b8dc7d4d5b26e184a7698e22f9fe7d8ee3c90d4" API Annotations: AnnTilde missing In T10689a.hs, the fragment data instance Sing (z :: [a]) = z ~ '[] => SNil | forall (m :: a) (n :: [a]). z ~ (:) m n => SCons (Sing m) (Sing n) ends up with the AnnTilde annotations for the two tildes not attached to the final AST. This patch moves the AnnTilde to the right place. Closes #11321 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 19:25:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 19:25:44 -0000 Subject: [GHC] #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export Message-ID: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the following code fragment {{{#!hs {-# LANGUAGE PatternSynonyms #-} module ExportSyntax ( A(.., NoA), Q(F,..), G(T,..,U)) where }}} The second and third `..` are missing `AnnDotdot` annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 19:26:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 19:26:38 -0000 Subject: [GHC] #11321: API Annotations: AnnTilde missing In-Reply-To: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> References: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> Message-ID: <059.5531fe4a2fa9c3192b0bf82454903b8e@haskell.org> #11321: API Annotations: AnnTilde missing -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | ApiAnnotations 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 alanz): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 19:27:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 19:27:49 -0000 Subject: [GHC] #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export In-Reply-To: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> References: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> Message-ID: <059.8966333f273610388ff1ad72f5386579@haskell.org> #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * failure: Other => Incorrect API annotation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 20:13:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 20:13:37 -0000 Subject: [GHC] #11333: GHCi does not discharge satisfied constraints Message-ID: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> #11333: GHCi does not discharge satisfied constraints ----------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- Don't know if this is the intended behaviour (GHCi, version 8.1.20151231), with the new extension TypeApplications. For the function [https://hackage.haskell.org/package/base-4.8.1.0/docs /Text-Show.html#v:show show]: {{{#!hs Prelude> :set -XTypeApplications Prelude> :t show show :: Show a => a -> String Prelude> :t show @Int show @Int :: Show Int => Int -> String }}} And the function [https://hackage.haskell.org/package/base/docs/Data- Typeable.html#v:eqT eqT] (`:: forall a b. (Typeable a, Typeable b) => Maybe (a :~: b)`): {{{#!hs Prelude> :set -XTypeApplications Prelude> import Data.Typeable Prelude Data.Typeable> :t eqT eqT :: forall k1 (a :: k1) (b :: k1). (Typeable a, Typeable b) => Maybe (a :~: b) Prelude Data.Typeable> :t eqT eqT :: forall k1 (a :: k1) (b :: k1). (Typeable a, Typeable b) => Maybe (a :~: b) Prelude Data.Typeable> :t eqT @Int eqT @Int :: (Typeable Int, Typeable b) => Maybe (Int :~: b) }}} Should the types of `show @Int` and `eqT @Int` not be `Int -> String` and `(Typeable b) => Maybe (Int :~: b)` respectively? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 20:19:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 20:19:24 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor Message-ID: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's what I did in GHCi to trigger the panic: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160101: http://www.haskell.org/ghc/ :? for help ?> :set -XDataKinds ?> :m Data.Typeable Data.Functor.Compose ?> typeOf (Proxy :: Proxy 'Compose) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160101 for x86_64-unknown-linux): piResultTy * TYPE 'Lifted * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Enabling `-XPolyKinds` doesn't trigger the error, though; #10343 will be triggered instead: {{{ ?> :set -XPolyKinds ?> typeOf (Proxy :: Proxy 'Compose) :5:1: error: ? No instance for (Typeable a0) arising from a use of ?typeOf? ? In the expression: typeOf (Proxy :: Proxy Compose) In an equation for ?it?: it = typeOf (Proxy :: Proxy Compose) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 21:14:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 21:14:16 -0000 Subject: [GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) Message-ID: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 1 23:32:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jan 2016 23:32:25 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.c8184f417683aa4c74c19608c7eb56a7@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by sboo): Could we add this? {{{#!hs import System.Mem.StableName instance Eq1 StableName where liftEq _ = eqStableName }}} I didn't see it in https://phabricator.haskell.org/D1543 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 00:52:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 00:52:16 -0000 Subject: [GHC] #10161: GHC does not relink if a library's code changed In-Reply-To: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> References: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> Message-ID: <057.1eeecb42af5f56feb4c3b909d36f80e8@haskell.org> #10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10966 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): There are a few ways to go about fixing this, but we have to be careful to keep GHC's compilation results deterministic. One consequence of this is that we CANNOT store the paths that were linked to produce the final executable in the executable: we don't want to bake those paths into the build product. But then how does GHC know what to query in order to find out if linking is necessary? My conclusion is that GHC has to (1) somehow run ld in a dry run mode (I could see no flag which actually implemented this) or (2) reimplement ld's library finding logic ourselves, so that we can guess what the actual files we're going to depend on are and then make a linking decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 00:52:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 00:52:58 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.ef354e6e8852fd05dff3b7c7efb77a8a@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1707 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 00:54:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 00:54:38 -0000 Subject: [GHC] #11297: CmmSwitchTest fails on 32-bit platforms In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.05073bab5c35d7ad35d773b766157158@haskell.org> #11297: CmmSwitchTest fails on 32-bit platforms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Test Suite -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 00:55:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 00:55:00 -0000 Subject: [GHC] #11297: CmmSwitchTest is broken on 32-bit platforms (was: CmmSwitchTest fails on 32-bit platforms) In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.2645f697f250815f52ae604158c6ca01@haskell.org> #11297: CmmSwitchTest is broken on 32-bit platforms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 01:20:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 01:20:33 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.5d9bb4540415f3d6ef32219f143ab80d@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by RyanGlScott): We definitely need to add a lot more `Eq1`/`Eq2`/etc. instances than what are currently provided. I didn't include any instances that weren't from `transformers` in Phab:D1543 to keep the migration simple. Another reason I held off on new instances is that I'd like to be able to derive `Eq1`/`Eq2`/etc. with a new language extension (for which I haven't though a good name yet?`DeriveLiftedClasses` perhaps?) to eliminate a lot of the inevitable boilerplate. If you really need an `Eq1 StableName` instance right now, feel free to submit a patch to Phabricator?but I doubt I'll get around to it until later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 02:25:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 02:25:34 -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.d7f590dc82ca1ef2f02e51d3480a0384@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Upon further thought, the new behavior is actually less broken than the old behavior, for a certain definition of broken. Consider the typing rule for function applications, as in the "Practical Type Inference" and "Visible Type Application" papers (they're the same, in this respect): {{{ G |- e1 => s1 -> s2 G |- e2 <= s1 ---------------- App G |- e1 e2 => s2 }}} Here, `=>` indicates type inference, while `<=` indicates type checking. There is no type checking rule for applications. So this means that any type expected by the context is simply not propagated down when checking the individual pieces. Given this fact, we can think about `pure Nothing` in a vacuum, without any type expected by its context. We see `pure :: forall f. Applicative f => forall a. a -> f a`. We guess a type (call it `s`) for `a` and then check `Nothing` against `s`. Without `ImpredicativeTypes`, `s` is constrained to be a tau-type -- that is, with no foralls anywhere. Thus, `Nothing :: forall a. Maybe a` must be instantiated to `Nothing :: Maybe t` for some `t`. But with `ImpredicativeTypes`, `s` can have foralls. So GHC doesn't instantiate, as it has no good reason to. It infers `pure @f @(forall a. Maybe a) Nothing :: f (Maybe (forall a. Maybe a))`. This is fully correct behavior. Then, when GHC checks that inferred type against the expected type `f (Maybe b)` (for some known skolem `b`) the check fails. So, the behavior we see is entirely predictable given the published typing rules when you relax the restriction around tau-types. And that's why I say it's less broken than the old behavior. On the other hand, it is sad that `ImpredicativeTypes` fails to accept Haskell98. Simon has cooked up a scheme that, I believe, will fix this case (written up at wiki:Typechecking), but that won't make it for 8.0, I would think. (Unless Simon wants to implement that plan in short order!) The key bit is that it comes up with a "checking" (that is, `<=`) rule for function application that propagates information down, forcing instantiation of `Nothing`, as desired. In any case, this isn't a quick fix and so I will remove it from my queue, as investing time in patching together `ImpredicativeTypes` seems less useful than other ways of using that precious resource. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 06:52:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 06:52:23 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.7448c03ee3fb72174ca0657ad17aaa59@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bheklilr): Replying to [comment:24 thomie]: > Unassigning, because of lack of progress. > > Maybe somebody else wants to give this a shot? @bheklilr? Sure, I'll give it a shot. It'll be a few days until I can look at it, the holidays have been keeping me busy (hence my delayed response), but I think I could take a stab at it sometime this month. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 10:18:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 10:18:03 -0000 Subject: [GHC] #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export In-Reply-To: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> References: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> Message-ID: <059.1de5a1f29ef7925f05418e6135715ee9@haskell.org> #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"f5ad1f0301f29e0631d3923dde3d5829b5ef8a53/ghc" f5ad1f0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5ad1f0301f29e0631d3923dde3d5829b5ef8a53" AnnDotDot missing for Pattern Synonym export For the following code fragment {-# LANGUAGE PatternSynonyms #-} module ExportSyntax ( A(.., NoA), Q(F,..), G(T,..,U)) where The second and third .. are missing AnnDotdot annotations. Closes #11332 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 10:55:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 10:55:54 -0000 Subject: [GHC] #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export In-Reply-To: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> References: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> Message-ID: <059.70a47eaeccba77e7ea65fa96667e73b4@haskell.org> #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Merged to GHC 8.0 via 8de477525418eb1f5f475b928a24ed57f1e99e24 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:26:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:26:45 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.150b66aeb5e36930dc7c81e11230f7b4@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Changes (by hvr): * owner: gkaracha => * status: closed => new * resolution: fixed => Comment: I just had matrix.h.h.o thrashing due to `text-icu` still requiring over 10GiB with yesterdays GHC 8.0 snapshot :-( I tried compiling `text-icu-0.7.0.1:Data.Text.ICU.Regex.Internal` on my workstation (with swap-space disabled) takes over 30GiB, until the OOM killer finally kicks in: {{{ [19687.231184] Out of memory: Kill process 18811 (ghc) score 929 or sacrifice child [19687.231186] Killed process 18811 (ghc) total-vm:1074146932kB, anon- rss:30410192kB, file-rss:0kB }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:27:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:27:15 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms Message-ID: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached file crashes: {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Prelude.last: empty list }}} I wasn't able to shrink the example further despite many attepts. Tested on GHC 7.8.3 and 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:27:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:27:27 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms In-Reply-To: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> References: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> Message-ID: <063.0c6498a7ff352b42b7e7c85f51fafc78@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by baramoglo): * Attachment "Bug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:34:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:34:20 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms In-Reply-To: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> References: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> Message-ID: <063.3dbe840be5861d166c302a85325104d8@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by baramoglo): Forgot to say that I'm able to work around the problem by changing the last line to {{{#!hs fun (Sym (prj -> Just B) :$ _) = undefined }}} So this is not a blocker for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:35:41 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.73d631929d87f27472915c027a8f3808@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: wontfix | Keywords: AMP, report- | impact 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:D510 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I am also one of these programmers who care about portability. How about creating a Haskell 2010 report with an addendum? It would maintain the language part of Haskell 2010 but add the modules Control.Applicative, Data.Monoid, Data.Foldable, Data.Traversable. I have several packages that use very basic functionality and I would like to show this by importing haskell2010 or haskell2010add. Alternatively, the split-base project would serve my needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:39:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:39:05 -0000 Subject: [GHC] #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export In-Reply-To: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> References: <044.20f2b2478d98ac370499558b9d7e1b9c@haskell.org> Message-ID: <059.9345bd7d3135059390a6c376e3657eff@haskell.org> #11332: APIAnnotations: AnnDotDot missing for Pattern Synonym export -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:40:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:40:43 -0000 Subject: [GHC] #11321: API Annotations: AnnTilde missing In-Reply-To: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> References: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> Message-ID: <059.68cc3dd4aa3b866400c602ead04cb5bf@haskell.org> #11321: API Annotations: AnnTilde missing -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | ApiAnnotations 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 alanz): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:45:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:45:58 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.bd65e7c70a4ca5e86f6a15862e87cdd2@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 12:57:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 12:57:28 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms In-Reply-To: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> References: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> Message-ID: <063.5c266ac5d58f794f7b9e8a2d38a5fdbd@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:10:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:10:53 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.aea65c2c90abc69cf096c943c7db921e@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): I tried to collect the relevant changes from the patch, but in most cases could not reproduce the speedups cdk reported. Only for the {{{lookup}}} function the runtime changed measurable (it improved even more, around 78% faster than the current implementation). Pulling the {{{ForeignPtr}}} out of the {{{IORef}}} could make sense, but I could not measure an impact on performance. A thing I find surprising is the first argument in {{{updateWith.go}}}, which seems to be totally unused. Is this the correct behavior? Anyway, I created a second patch which removes the unused argument (and changes the first element of the return value to a {{{Bool}}}, as it is just tested for being {{{Nothing}}}), if it is just a leftover from an earlier version of the function. The change has no impact on performance, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:16:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:16:24 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.f75f9f4f5c943239964a8d6cbab34882@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * status: infoneeded => patch Comment: Okay, I just get {{{IndexError: pop from empty list}}} if I try to attach a file, so I put it here... Improving {{{lookup}}}: {{{ --- a/GHC/Event/IntTable.hs +++ b/GHC/Event/IntTable.hs @@ -45,11 +45,12 @@ lookup :: Int -> IntTable a -> IO (Maybe a) lookup k (IntTable ref) = do let go Bucket{..} - | bucketKey == k = return (Just bucketValue) + | bucketKey == k = Just bucketValue | otherwise = go bucketNext - go _ = return Nothing + go _ = Nothing it at IT{..} <- readIORef ref - go =<< Arr.read tabArr (indexOf k it) + bkt <- Arr.read tabArr (indexOf k it) + return (go bkt) new :: Int -> IO (IntTable a) new capacity = IntTable `liftM` (newIORef =<< new_ capacity) }}} Cleaning up {{{updateWith}}}: {{{ --- a/GHC/Event/IntTable.hs +++ b/GHC/Event/IntTable.hs @@ -13,7 +13,7 @@ import Data.Bits ((.&.), shiftL, shiftR) import Data.IORef (IORef, newIORef, readIORef, writeIORef) -import Data.Maybe (Maybe(..), isJust, isNothing) +import Data.Maybe (Maybe(..), isJust) import Foreign.ForeignPtr (ForeignPtr, mallocForeignPtr, withForeignPtr) import Foreign.Storable (peek, poke) import GHC.Base (Monad(..), (=<<), ($), const, liftM, otherwise, when) @@ -123,20 +123,17 @@ updateWith f k (IntTable ref) = do it at IT{..} <- readIORef ref let idx = indexOf k it - go changed bkt at Bucket{..} - | bucketKey == k = - let fbv = f bucketValue - !nb = case fbv of - Just val -> bkt { bucketValue = val } - Nothing -> bucketNext - in (fbv, Just bucketValue, nb) - | otherwise = case go changed bucketNext of + go bkt at Bucket{..} + | bucketKey == k = case f bucketValue of + Just val -> let !nb = bkt { bucketValue = val } in (False, Just bucketValue, nb) + Nothing -> (True, Just bucketValue, bucketNext) + | otherwise = case go bucketNext of (fbv, ov, nb) -> (fbv, ov, bkt { bucketNext = nb }) - go _ e = (Nothing, Nothing, e) - (fbv, oldVal, newBucket) <- go False `liftM` Arr.read tabArr idx + go e = (True, Nothing, e) + (del, oldVal, newBucket) <- go `liftM` Arr.read tabArr idx when (isJust oldVal) $ do Arr.write tabArr idx newBucket - when (isNothing fbv) $ + when del $ withForeignPtr tabSize $ \ptr -> do size <- peek ptr poke ptr (size - 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:24:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:24:49 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block Message-ID: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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 pointed out in Phab:D1532, the DWARF unwinding information that we produce is currently a bit oversimplified. Namely, we produce exactly one unwind table per Cmm block. This works reasonably well in most cases since we most Cmm blocks have the form, {{{ aProcedure() { casl: -- we just entered the procedure, so the unwinding is trivial. unwind Sp = Sp -- we push some values onto the stack... I64[Sp - 16] = ... I64[Sp - 8] = ... -- and before leaving the block we update Sp. Sp = Sp - 16; -- technically our unwind information is now a lie call aFunction() returns to casd; casd: -- we inherit the unwind information from the state of the stack when we -- left the preceding block (casl) unwind Sp = Sp + 16 R2 = I64[Sp + 8]; -- pop off that which we pushed Sp = Sp + 16; call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; }}} Here there is a narrow window where our unwind information is technically wrong: between updating `Sp` in `casl` and calling into `aFunction`. Note that after we arrive in `aFunction` we are safe, since our return address is `casd`, which has the correct unwinding information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:25:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:25:22 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block In-Reply-To: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> References: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> Message-ID: <061.8f74497932b54116ec2c641c655a1503@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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 bgamari: Old description: > As pointed out in Phab:D1532, the DWARF unwinding information that we > produce is > currently a bit oversimplified. Namely, we produce exactly one unwind > table per > Cmm block. This works reasonably well in most cases since we most Cmm > blocks > have the form, > {{{ > aProcedure() { > casl: > -- we just entered the procedure, so the unwinding is trivial. > unwind Sp = Sp > -- we push some values onto the stack... > I64[Sp - 16] = ... > I64[Sp - 8] = ... > -- and before leaving the block we update Sp. > Sp = Sp - 16; > -- technically our unwind information is now a lie > call aFunction() returns to casd; > > casd: > -- we inherit the unwind information from the state of the stack when > we > -- left the preceding block (casl) > unwind Sp = Sp + 16 > R2 = I64[Sp + 8]; > -- pop off that which we pushed > Sp = Sp + 16; > call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; > }}} > Here there is a narrow window where our unwind information is technically > wrong: > between updating `Sp` in `casl` and calling into `aFunction`. > > Note that after we arrive in `aFunction` we are safe, since our return > address > is `casd`, which has the correct unwinding information. New description: As pointed out in Phab:D1532, the DWARF unwinding information that we produce is currently a bit oversimplified. Namely, we produce exactly one unwind table per Cmm block. This, however, produces subtly incorrect debug information, {{{ aProcedure() { casl: -- we just entered the procedure, so the unwinding is trivial. unwind Sp = Sp -- we push some values onto the stack... I64[Sp - 16] = ... I64[Sp - 8] = ... -- and before leaving the block we update Sp. Sp = Sp - 16; -- technically our unwind information is now a lie call aFunction() returns to casd; casd: -- we inherit the unwind information from the state of the stack when we -- left the preceding block (casl) unwind Sp = Sp + 16 R2 = I64[Sp + 8]; -- pop off that which we pushed Sp = Sp + 16; call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; }}} Here there is a narrow window where our unwind information is technically wrong: between updating `Sp` in `casl` and calling into `aFunction`. Note that after we arrive in `aFunction` we are safe, since our return address is `casd`, which has the correct unwinding information. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:25:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:25:40 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block In-Reply-To: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> References: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> Message-ID: <061.90e304458b7bd335c479a8dd78575fa6@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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 bgamari: Old description: > As pointed out in Phab:D1532, the DWARF unwinding information that we > produce is > currently a bit oversimplified. Namely, we produce exactly one unwind > table per > Cmm block. This, however, produces subtly incorrect debug information, > {{{ > aProcedure() { > casl: > -- we just entered the procedure, so the unwinding is trivial. > unwind Sp = Sp > -- we push some values onto the stack... > I64[Sp - 16] = ... > I64[Sp - 8] = ... > -- and before leaving the block we update Sp. > Sp = Sp - 16; > -- technically our unwind information is now a lie > call aFunction() returns to casd; > > casd: > -- we inherit the unwind information from the state of the stack when > we > -- left the preceding block (casl) > unwind Sp = Sp + 16 > R2 = I64[Sp + 8]; > -- pop off that which we pushed > Sp = Sp + 16; > call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; > }}} > Here there is a narrow window where our unwind information is technically > wrong: > between updating `Sp` in `casl` and calling into `aFunction`. > > Note that after we arrive in `aFunction` we are safe, since our return > address > is `casd`, which has the correct unwinding information. New description: As pointed out in Phab:D1532, the DWARF unwinding information that we produce is currently a bit oversimplified. Namely, we produce exactly one unwind table per Cmm block. This, however, produces subtly incorrect debug information, {{{ aProcedure() { casl: -- we just entered the procedure, so the unwinding is trivial. unwind Sp = Sp -- we push some values onto the stack... I64[Sp - 16] = ... I64[Sp - 8] = ... -- and before leaving the block we update Sp. Sp = Sp - 16; -- technically our unwind information is now a lie call aFunction() returns to casd; casd: -- we inherit the unwind information from the state of the stack when we -- left the preceding block (casl) unwind Sp = Sp + 16 R2 = I64[Sp + 8]; -- pop off that which we pushed Sp = Sp + 16; call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; } }}} Here there is a narrow window where our unwind information is technically wrong: between updating `Sp` in `casl` and calling into `aFunction`. Note that after we arrive in `aFunction` we are safe, since our return address is `casd`, which has the correct unwinding information. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:25:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:25:46 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block In-Reply-To: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> References: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> Message-ID: <061.63f6cb74edd1a6c68b0f8cdcfa603309@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:30:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:30:40 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block In-Reply-To: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> References: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> Message-ID: <061.6d59379f1b0efcc616236cae9257171a@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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): In principle this ought not to be too hard to fix: 1. Fix `CmmLayoutStack.maybeAddSpAdj` to add a `CmmUnwind` node after the `CmmAssign`. 2. Fix `Debug.extractUnwind` to properly emit tables for all unwind nodes in a block. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:33:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:33:16 -0000 Subject: [GHC] #11338: Unwind information is incorrect in region surrounding a safe foreign call Message-ID: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11337 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Safe foreign calls can occur at the end of a block. Like #11337, these produce incorrect debug information. However, the situation is worse in the case of foreign calls since these return to the calling block. This means that we are currently unable to unwind out of a safe foreign call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:34:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:34:06 -0000 Subject: [GHC] #11338: Unwind information is incorrect in region surrounding a safe foreign call In-Reply-To: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> References: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> Message-ID: <061.2dd2f604ea9f2c4a72f75fbfeedbbee7@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Debugging information is incorrect -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 13:34:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 13:34:14 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block In-Reply-To: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> References: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> Message-ID: <061.92bc790ebd10429171b08fd10b9dbadc@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Debugging information is incorrect -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 14:23:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 14:23:50 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.7836ca41749ad0534186a59f52e4895d@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:8 hvr]: > I tried compiling `text-icu-0.7.0.1:Data.Text.ICU.Regex.Internal` on my workstation (with swap-space disabled) takes over 30GiB, until the OOM killer finally kicks in: > > {{{ > [19687.231184] Out of memory: Kill process 18811 (ghc) score 929 or sacrifice child > [19687.231186] Killed process 18811 (ghc) total-vm:1074146932kB, anon- rss:30410192kB, file-rss:0kB > }}} Hmmmm, how come you consider this an instance of #11303 and not #11276? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 14:27:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 14:27:07 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.3003fdb499e7f2c50ab04db32dbf1459@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 14:53:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 14:53:26 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects In-Reply-To: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> References: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> Message-ID: <065.c29fca41ada101f390426034738eb51d@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by snowleopard): Replying to [comment:2 thomie]: > I was hoping we could get rid of `-split-objs`, now that #8405 is implemented (function-sections). Interesting. We can certainly experiment with function sections in the new build system, but as I understand we still need to provide full support for split objects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 16:25:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 16:25:48 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.60d5b95e0f7458b2c9522926875b882e@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:9 gkaracha]: > Hmmmm, how come you consider this an instance of #11303 and not #11276? Mostly guessed so, because #11276 talks about exponential time, rather than exponential memory usage :-) Do you need me to provide you a smaller testcase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 16:48:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 16:48:27 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.cf5041279f5e5d14375aa3c074e22824@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by mpickering): I suspect #11276 is also a memory issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 17:03:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 17:03:03 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.d9367aff0368110b56cb44e30bcf25ab@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another reason it's probably #11276 instead is because the same workaround can be applied to `text-icu`: {{{#!diff index 38765d4..c31f4b6 100644 --- a/Data/Text/ICU/Regex/Internal.hsc +++ b/Data/Text/ICU/Regex/Internal.hsc @@ -174,6 +174,7 @@ toURegexpOpts = foldl go (0,-1,-1) where go (!flag,work,stack) opt = (flag+flag',work',stack') where + flag' :: URegexpFlag flag' = case opt of CaseInsensitive -> #const UREGEX_CASE_INSENSITIVE Comments -> #const UREGEX_COMMENTS }}} Adding a type signature makes the rest of `text-icu` compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 17:07:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 17:07:44 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.e5fda443f10d9aac5ebba9292eb5bdfd@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:10 hvr]: > Mostly guessed so, because #11276 talks about exponential time, rather than exponential memory usage :-) I see. Personally, I think that all the recent bug reports concerning the checker were not strictly speaking bugs, rather improvements needed to check realistic code. Yet, #11276 and the behaviour on `text-icu-0.7.0.1` seems like an actual bug and I feel they have the same source. > Do you need me to provide you a smaller testcase? Yes, if it is not too much trouble! Even with Matthew's useful comments I still haven't found the source of #11276, maybe one more test case can shed some more light on this. :-) Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 17:10:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 17:10:48 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.fab00eda4425ee779fc55412eaf9dbaa@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:12 RyanGlScott]: > Another reason it's probably #11276 instead is because the same workaround can be applied to `text-icu`: > {...} > Adding a type signature makes the rest of `text-icu` compile. Ah, great! So `flag'` is the source of the problem. Then yes, they are definitely connected, probably something goes wrong with the types I assign to the initial uncovered set (I get it from the signature/inferred type). Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 17:34:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 17:34:40 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 Message-ID: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- The following code (extracted from hackage:microlens) type-checks on GHC 7.10 but '''not''' on GHC 8.0/8.1: {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Failing where import Control.Applicative ( Const(Const, getConst) ) import Data.Functor.Identity ( Identity(Identity) ) type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t failing :: forall s t a b . Traversal s t a b -> Traversal s t a b -> Traversal s t a b failing left right afb s = case pins t of [] -> right afb s _ -> t afb where -- t :: (a -> f b) -> f t -- TYPECHECKS with GHC 7.10, but not with GHC 8.x: Bazaar { getBazaar = t } = left sell s -- FAILS TO TYPECHECK with GHC 7.10 and GHC 8.x: -- t = getBazaar (left sell s) sell :: a -> Bazaar a b b sell w = Bazaar ($ w) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] pins f = getConst (f (\ra -> Const [Identity ra])) newtype Bazaar a b t = Bazaar { getBazaar :: (forall f. Applicative f => (a -> f b) -> f t) } instance Functor (Bazaar a b) where fmap f (Bazaar k) = Bazaar (fmap f . k) instance Applicative (Bazaar a b) where pure a = Bazaar $ \_ -> pure a Bazaar mf <*> Bazaar ma = Bazaar $ \afb -> mf afb <*> ma afb }}} The following error is emitted on GHC 8.0: {{{ failing.hs:13:11: error: ? Couldn't match type ?f? with ?Const [Identity a]? ?f? is a rigid type variable bound by the type signature for: failing :: forall (f :: * -> *). Applicative f => Traversal s t a b -> Traversal s t a b -> (a -> f b) -> s -> f t at failing.hs:11:1 Expected type: a -> Const [Identity a] b Actual type: a -> f b ? In the first argument of ?t?, namely ?afb? In the expression: t afb In a case alternative: _ -> t afb ? Relevant bindings include t :: (a -> Const [Identity a] b) -> Const [Identity a] t (bound at failing.hs:18:26) sell :: a -> Bazaar a b b (bound at failing.hs:24:5) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] (bound at failing.hs:27:5) afb :: a -> f b (bound at failing.hs:11:20) right :: Traversal s t a b (bound at failing.hs:11:14) left :: Traversal s t a b (bound at failing.hs:11:9) failing :: Traversal s t a b -> Traversal s t a b -> Traversal s t a b (bound at failing.hs:11:1) }}} I don't understand why `Bazaar t = ...` vs `t = getBazaar ...` makes a difference in GHC 7.10 at all. So I'm not sure if this is a regression or actually something that got fixed in GHC 8.0... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 17:45:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 17:45:40 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.6864d03355ae24b4b5b8f5033c20ffc3@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As of 78daabc514e220ef52645b175a60ec39cfd4eeb1 the follow tests still fail, {{{ Unexpected results from: TEST="T2552 T2552 TH_spliceE5_prof TH_spliceE5_prof_ext outofmem linker_unload recomp011 T10359 T9203 T7257 lazy-bs-alloc T5321FD T5030 T4801 T5631 T5837 T9872a T9872d T9872b T3064 T9872c T1969 T5321Fun T783 T9233 T9961 haddock.Cabal haddock.compiler haddock.base" OVERALL SUMMARY for test run started at Sat Jan 2 17:03:18 2016 CET 1:34:00 spent to go through 4937 total tests, which gave rise to 16678 test cases, of which 11772 were skipped 66 had missing libraries 4738 expected passes 73 expected failures 1 caused framework failures 1 unexpected passes 6 unexpected failures 22 unexpected stat failures Unexpected passes: profiling/should_run T2552 (prof) Unexpected failures: driver/recomp011 recomp011 [bad stdout] (normal) profiling/should_run T2552 [bad profile] (profasm) rts linker_unload [bad exit code] (normal) rts outofmem [bad stdout] (normal) th TH_spliceE5_prof [bad exit code] (normal) th TH_spliceE5_prof_ext [bad exit code] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 18:22:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 18:22:20 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM Message-ID: <046.a62213e25c1394c85d381cec278c08db@haskell.org> #11340: linker_unload test fails on ARM --------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- The `linker_unload` test segfaults on ARM. I thought I had fixed it in #11299 but apparently not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 18:26:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 18:26:01 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.2c59ea0132040e333e8aa80a885842a4@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): The crash is quite reproducible. It generally looks like this, {{{ $ gdb --args linker_unload /mnt/ext/exp/ghc/inplace/lib +RTS GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 ... Reading symbols from linker_unload...done. (gdb) run /mnt/ext/exp/ghc/inplace/lib +RTS -Dl 2> h Starting program: /mnt/ext/exp/ghc/testsuite/tests/rts/linker_unload /mnt/ext/exp/ghc/inplace/lib +RTS -Dl 2> h [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 Program received signal SIGSEGV, Segmentation fault. 0xb8f6cf70 in ?? () (gdb) info reg r0 0xb6ff7278 3070194296 r1 0x4507d40 72383808 r2 0xbefff578 3204445560 r3 0xb6ff7214 3070194196 r4 0xbefff3c0 3204445120 r5 0xbefff3c4 3204445124 r6 0xd8 216 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0xb6fff000 3070226432 r11 0xbefff31c 3204444956 r12 0x45003f4 72352756 sp 0xbefff318 0xbefff318 lr 0xb6ff7228 -1224773080 pc 0xb8f6cf70 0xb8f6cf70 cpsr 0x800f0010 -2146500592 (gdb) bt #0 0xb8f6cf70 in ?? () #1 0xb6ff7228 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) x/i $lr 0xb6ff7228: pop {r11, pc} (gdb) x/32i $lr-64 0xb6ff71e8: ldr r3, [r11, #-24] 0xb6ff71ec: mov r0, r3 0xb6ff71f0: bl 0xb8f6cf50 0xb6ff71f4: str r0, [r11, #-16] 0xb6ff71f8: ldr r3, [r11, #-20] 0xb6ff71fc: mov r0, r3 0xb6ff7200: bl 0xb8f6cf60 0xb6ff7204: ldr r3, [r11, #-16] 0xb6ff7208: mov r0, r3 0xb6ff720c: sub sp, r11, #12 0xb6ff7210: pop {r4, r5, r11, pc} 0xb6ff7214: push {r11, lr} 0xb6ff7218: add r11, sp, #4 0xb6ff721c: movw r0, #29304 ; 0x7278 0xb6ff7220: movt r0, #46847 ; 0xb6ff 0xb6ff7224: bl 0xb8f6cf70 0xb6ff7228: pop {r11, pc} 0xb6ff722c: andeq r0, r0, r0 0xb6ff7230: ; instruction: 0xb6fee838 ... }}} Looks like reasonable code to me. Unfortunately it appears that the code at `*$pc` is total garbage. Moreover, looking at the linker output it seems that no code was ever mapped at this address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 18:42:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 18:42:50 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.b49c63fcf4ab23fde35759656d5497d3@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): Very interesting... `$lr` falls on this relocation, {{{ Rel entry 49 is raw( 0x21c 0x461c)lookupSymbol: looking up foreignExportStablePtr lookupSymbol: value of foreignExportStablePtr is 0x3ece80c `foreignExportStablePtr' resolves to 0x3ece80c Reloc: P = 0xb6ff7224 S = 0x3ece80c A = 0xebfffffe }}} Which happens to be the last relocation of the `.text` section of `Test.o`, {{{ RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE ... 00000218 R_ARM_MOVT_ABS Test_zdfstableZZC0ZZCmainZZCTestZZCf_closure 0000021c R_ARM_CALL foreignExportStablePtr }}} Might this be causal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 18:53:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 18:53:55 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.7412e5e52687fa70ed306ce2440d278d@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): Interesting, it appears that the linker built a symbol extra for this symbol due to a long jump. With this patch, {{{#!patch diff --git a/rts/Linker.c b/rts/Linker.c index cb90c97..0cf3fe5 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -2731,6 +2731,7 @@ static int ocAllocateSymbolExtras( ObjectCode* oc, int count, int first ) if (oc->symbol_extras != NULL) { memset( oc->symbol_extras, 0, sizeof (SymbolExtra) * count ); + IF_DEBUG(linker, debugBelch("Symbol extras at %p\n", oc->symbol_extras)); } oc->first_symbol_extra = first; @@ -5019,7 +5020,7 @@ do_Elf_Rel_relocations ( ObjectCode* oc, char* ehdrC, int is_target_thm=0, T=0; #endif - IF_DEBUG(linker,debugBelch( "Rel entry %3d is raw(%6p %6p)", + IF_DEBUG(linker,debugBelch( "Rel entry %3d is raw(%6p %6p): ", j, (void*)offset, (void*)info )); if (!info) { IF_DEBUG(linker,debugBelch( " ZERO" )); @@ -5115,6 +5116,9 @@ do_Elf_Rel_relocations ( ObjectCode* oc, char* ehdrC, // The -8 below is to compensate for PC bias offset = (StgWord32) &extra->jumpIsland - P - 8; offset &= ~1; // Clear thumb indicator bit + IF_DEBUG(linker, debugBelch("Made symbol extra %p due to %s\n", + &extra->jumpIsland, + overflow ? "overflow" : "R_ARM_JUMP24 to Thumb target")); } else if (is_target_thm && ELF_R_TYPE(info) == R_ARM_CALL) { StgWord32 cond = (*word & 0xf0000000) >> 28; if (cond == 0xe) { @@ -5123,6 +5127,8 @@ do_Elf_Rel_relocations ( ObjectCode* oc, char* ehdrC, *word = (*word & ~0x01ffffff) | ((offset >> 2) & 0x00ffffff) // imm24 | ((offset & 0x2) << 23); // H + + IF_DEBUG(linker, debugBelch("Changed BL to BLX at %p\n", word)); break; } else { errorBelch("%s: Can't transition from ARM to Thumb when cond != 0xe\n", }}} I see, {{{ Rel entry 49 is raw( 0x21c 0x461c): lookupSymbol: looking up foreignExportStablePtr lookupSymbol: value of foreignExportStablePtr is 0x3ece80c `foreignExportStablePtr' resolves to 0x3ece80c Reloc: P = 0xb6ff7224 S = 0x3ece80c A = 0xebfffffe Made symbol extra 0xb4f6cf70 due to overflow }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 19:36:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 19:36:09 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior In-Reply-To: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> References: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> Message-ID: <068.73101a434154f8ccbf5f9b3eba632635@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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:D1422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 20:08:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 20:08:50 -0000 Subject: [GHC] #10663: ghci ignores stuff after an import command and a semicolon In-Reply-To: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> References: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> Message-ID: <062.b52fba3ecade86677c42bb8eb86c7288@haskell.org> #10663: ghci ignores stuff after an import command and a semicolon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer 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:D1726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rdragon): * differential: => Phab:D1726 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 20:47:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 20:47:54 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.57fc2c1b5b5b0ce911ea0e6bd6e5b224@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Rev(s): Phab:D211, Wiki Page: | Phab:D1615 -------------------------------------+------------------------------------- Comment (by Lemming): I defined a type like this one: {{{ newtype T a = Cons (Eq a => b) }}} and GHC-7.10 gave me the warning: {{{ Variable ?b? is implicitly quantified due to a context Use explicit forall syntax instead. This will become an error in GHC 7.12. In the type ?Eq a => b? In the definition of data constructor ?Cons? }}} In this case my mistake was to forget to add the 'b' as type parameter, thus the advice "Use explicit forall syntax instead" was misleading. Could you write instead "Use explicit forall syntax instead or add a type parameter"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 22:07:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 22:07:48 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms In-Reply-To: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> References: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> Message-ID: <063.f1b1b02976ed991a3ecdea21d490772a@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Happily this works in HEAD, and hence (I expect -- someone pls check) GHC 8.0. I don't think we'll fix 7.10. Pattern synonyms have had a major re-work since then. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 22:09:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 22:09:47 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms In-Reply-To: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> References: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> Message-ID: <063.70b1c12d085a24078c39342e5295176d@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"256c2cfc1e3690cb4b07154b3a81d89d45625685/ghc" 256c2cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="256c2cfc1e3690cb4b07154b3a81d89d45625685" Test Trac #11336 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 23:01:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 23:01:23 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type Message-ID: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | 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: -------------------------------------+------------------------------------- Running this example: {{{#!hs {-# LANGUAGE GADTs, TemplateHaskell #-} module Main (main) where import Language.Haskell.TH type S = T data T a where MkT :: S Int $(return []) main :: IO () main = putStrLn $(reify ''T >>= stringE . pprint) }}} gives the following result: {{{ data Main.T (a_0 :: *) where Main.MkT :: Main.T GHC.Types.Int }}} Shouldn't the return type be `Main.S GHC.Types.Int` instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 23:40:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 23:40:37 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.c2596974d4036ef271a9107ece39b63c@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): Well, the good news is that I realized the source of the trouble. The bad news is I don't really know what to do about it. This test loads and unloads an object file dozens of times in succession. On ARM the linker builds a set of "symbol extras" which we use to relocate jumps which, * overflow the branch instructions' immediate field width (the ARM `b` and `bl` instructions are PC-relative with a signed 24-bit range) * require Thumb/ARM switch As it turns out, every time we load/unload the symbol extras region gets a bit farther away from the code we are loading. After 85 or so iterations the gap grows large enough that we can't jump from the code to the symbol extra (in particular it seems like the unlucky call is to `foreignExportStablePtr`). This is an unfortunate state of affairs. It would help if we were a bit more thorough in cleaning up while unloading. It used to be that we didn't unload code at all when "unloading" (see #8039) but this has since been fixed. Perhaps we still aren't letting go of symbol extras? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 2 23:52:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jan 2016 23:52:48 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.246edc6905e8de5dfedb3b5d39f3430c@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): * cc: goldfire (added) Comment: The bug might even be deeper than that. If I try using a more complex type synonym: {{{#!hs {-# LANGUAGE GADTs, TemplateHaskell #-} module Main (main) where import Language.Haskell.TH type S a = T data T a where MkT :: S Char Int $(return []) main :: IO () main = putStrLn $(reify ''T >>= stringE . pprint) }}} then it doesn't tell you that the type indices are both `Char` and `Int`: {{{ data Main.T (a_0 :: *) where Main.MkT :: Main.T GHC.Types.Int }}} The same thing is outputted even when the GADT return type appears as a "type index": {{{#!hs {-# LANGUAGE GADTs, TemplateHaskell #-} module Main (main) where import Language.Haskell.TH type Id a = a type S a = T data T a where MkT :: Id (S Char Int) $(return []) main :: IO () main = putStrLn $(reify ''T >>= stringE . pprint) }}} That brings up an interesting design question. Is the third field of `Gadt` (a `Name`) intended to be the outermost type application, and the fourth field (a `[Type]`) intended to be the types that to which the `Name` is applied? If so, then the "type index" returned in the above example is just `S Char Int`, so how should a Template Haskell programmer know that `a` is being refined to `Int`? Presumably, you'd have to do some tricky type arithmetic, which doesn't sit right to me. Perhaps it would be better to change `GadtC` to this: {{{#!hs data Con = ... | GadtC [Name] [BangType] Type [Type] }}} where the third field contains the return type as written in the source code (in the above example, `Id (S Char Int)`) and the fourth field contains the type indices after expanding type synonyms (in the above example, `Int`). Similarly for `RecGadtC`. Jan, Richard, what are your thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 00:04:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 00:04:27 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.efe344d0bd6dbe1a82db1539a2a0b1d8@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): So it appears that the m32 allocator gives us allocations successively higher in the address space for symbol extras, despite the fact that the previous extras have been freed. Odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 00:42:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 00:42:12 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.066e6cbe7d56d5fc414497824961b716@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): Looking a bit more at how m32 works, this behavior makes quite a bit of sense: it keeps a list of pages which it fills with small objects (which symbol extras are). Once a page is full it removes it from the active list. When an object in a non-active page is freed it decrements an object counter associated with that page. When the counter reaches zero, the page itself is freed. I can think of a few (imperfect) approaches to mitigate this, 1. don't use m32 for symbol extras 2. teach m32 to try harder to find memory in the needed range 3. teach m32 to replace freed pages on the active list instead of freeing them 4. just accept that object unloading on ARM is a bit broken and mark the test accordingly I'm currently leaning towards (4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 01:06:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 01:06:13 -0000 Subject: [GHC] #11342: Character kind Message-ID: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> #11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- We know and love the Symbol kind, but as far as I know it's not possible to analyse a Symbol type, as we would a String term. It would be nice to have a Character kind and some related type families: {{{#!hs data Character -- Pattern match a Symbol. 'Nothing when empty, 'Just '(head, tail) -- otherwise. type family UnconsSymbol (s :: Symbol) :: Maybe (Character, Symbol) -- Put a Character at the head of a Symbol. type family ConsSymbol (c :: Character) (s :: Symbol) :: Symbol -- Work with Characters. Ideally we'd have counterparts for every -- function on Data.Char. type family ToUpper (c :: Character) :: Character type family IsAlpha (c :: Character) :: Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 02:50:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 02:50:35 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.219c102b521c29ddc6edfbff9ab852ec@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): A couple initial observations: 1. The panic happens when ghc builds the ModIface, specifically when fingerprinting `GHC.Stack.Types.CallStack`. 2. The panic only occurs with `-O`. The module is so simple that the Core is unchanged by optimizations, but the optimized Core does include an unfolding that mentions the `CallStack` type. So, it looks like GHC is trying to fingerprint `CallStack` to write out the interface file, but fails because `GHC.Stack.Types` was never loaded. The question then is why did we not load `GHC.Stack.Types`? It's clearly imported by `GHC.Err`, the interface file confirms. But `-ddump-if-trace` doesn't mention `GHC.Stack.Types`.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 03:57:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 03:57:11 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.d80367c071389bdcdf103fb2afbd7028@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 ran into this problem a few weeks ago. It seems that the place where `GHC.Stack.Types` normally gets loaded is the `dsLookupDataCon` call in `DsBinds.dsEvCallStack`. I found this peculiar at the time (why doesn't it get loaded earlier?) but the original source of the error (for me) was elsewhere. When I fixed that (to produce an `EvCallStack`), the problem went away. I don't know why this all is happening, but the knowledge that that particular call of `dsLookupDataCon` triggers loading in the successful case was a bit hard-won, so I thought I'd share. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 09:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 09:00:56 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.b706630b8827cfa86e676dc7f9c7aabc@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rdragon): It looks like this issue has been fixed in GHC 7.10.2 or before. I can reproduce the problem with GHC 7.8.3, but not with 7.10.2. In both cases I use the 64-bit version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 10:24:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 10:24:22 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.4ae24953e07bf30f4d1895efd1f06a2b@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 jstolarek): Currently reifying a GADT data constructor tells us "what the user meant", not "what the user wrote", ie. type synonyms are expanded. I think the most important question is what should the GADT data constructor representation look like. I believe that TH should represent source code syntax. That said, your third example shows that the current representation is not sufficient. So I would propose to represent GADT data constructor as: {{{#!hs data Con = ... | GadtC [Name] [StrictType] Type }}} Where `Type` is the result type written by the user. In `TcSplice.reifyDataCon` we have access to `dcOrigResTy` field of a `DataCon`, which should allow us to reify original result type. {{{#!hs data T a where MkT :: a -> T a }}} Note that by ''result type'' of `MkT` I mean `T a`, not `a -> T a`. (I believe `dcOrigResTy` stores the latter). In this setting I don't think it is a good idea to store indices inside `GadtC`. This would duplicate information already stored inside the constructor and make it possible to create inconsistent data constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 11:34:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 11:34:30 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.e2e5cbd51e43386cf364dbbd86e6638d@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => goldfire Comment: Richard, I threw `git bisect` at this issue, and the winner was 2db18b8135335da2da9918b722699df684097be9 (aka Visible Type Application)! :-) Can you look at this and find out whether the type-checking failure is legitimate or not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 12:26:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 12:26:22 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.f1d8862cafd73f3fdf22f927430c36a4@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): Replying to [comment:2 jstolarek]: > In this setting I don't think it is a good idea to store indices inside `GadtC`. This would duplicate information already stored inside the constructor and make it possible to create inconsistent data constructors. That's a good point I hadn't thought of. We definitely don't want users to be able to splice in type indices that don't match up with the actual return type. I suppose the real type indices can always be found out through something like `expand` in `th-desugar`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 12:37:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 12:37:31 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.92f13356144c7cdbfc1f297198be721d@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 jstolarek): Replying to [comment:3 RyanGlScott]: > That's a good point I hadn't thought of. We definitely don't want users to be able to splice in type indices that don't match up with the actual return type. Just to be clear: TH syntax tree already allows to write all sorts of silliness that we have to catch later on in the pipeline. This would be another such thing. I just fear that the check would not be trivial. I also think that in most cases GADT result type simply includes indexed type constructor and having to duplicate the indices will be painful. > I suppose the real type indices can always be found out through something like `expand` in `th-desugar`. In such corner cases that you've demonstrated indices might be very hard (impossible?) to recover. But I think that's acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 12:56:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 12:56:23 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.a1e0b92fc292b043edb4d8b024fe6e22@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1728 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1728 Comment: As it turns out, the linker already implements a means of dealing with this: we simply need to set `USE_CONTIGUOUS_MMAP`. See Phab:D1728 for a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 13:27:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 13:27:10 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.fe9a042afae5f66ae611bc80a9a09582@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I updated the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 14:01:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 14:01:43 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.e706995f18d0970f4d61b161ecc3fa25@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): That actually makes a lot of sense, thanks! The CallStack tycon is wired- in, so the type-checker wouldn't have to load GHC.Types.Stack. The datacon is not, nor is the newer pushCallStack function we use in the desugarer, so that's why it would be loaded during desugaring. In this case we're not generating any CallStacks, so dsEvCallStack is not called, so the module is not loaded. Hrm.. What is the usual rule for loading modules that contain wired-in things? Or is it even necessary to fingerprint a wired-in thing? (By the way, how ''did'' you figure out what was triggering the load?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 14:17:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 14:17:01 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.5dbfb8211665156bce552efa5e6b3199@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by gkaracha): Ha, finally! It took more than I expected but I found the source: I do not understand why but GHC wraps all patterns in `CoPat`s: {{{#!hs Just (EventBeginDocument |> _R) Just (EventEndDocument |> _R) ... }}} Hence, the following match of `translatePat` (in `deSugar/Check.hs`) is triggered: {{{#!hs CoPat wrapper p ty -> do ps <- translatePat p (xp,xe) <- mkPmId2FormsSM ty let g = mkGuard ps (HsWrap wrapper (unLoc xe)) return [xp,g] }}} This means that, e.g. for the first clause, instead of the *expected*: {{{ Just EventBeginDocument }}} The following is generated: {{{ Just (d2JK (EventBeginDocument <- d2JK)) }}} And like this, we end up with a bunch of guards which make the checker explode. The reason I had it translated like this is that `CoPat`s are used for data families, where we have the original and a representation type constructor. Dropping the `wrapper` would give a type error (while it shouldn't) because the two constructors are different so the guaird translation allowed me to match against `d2JK` using the source type (original tyCon) and then match the guard `(EventBeginDocument <- d2JK)` using the internal type (representation tyCon) and avoid the mix-up. It will need some tinkering but I think I can find a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 14:27:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 14:27:22 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.89834dadddf96b16f87c0eefd85b9bda@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10592 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * testcase: => typecheck/should_compile/T10592 * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 15:29:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 15:29:46 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.d752fa51ea4cfa543f91161d441b97d9@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shubhaml): I'm willing to help @bheklilr with this. I'm a first-time contributor too. So far I've created a {{{--cleanup}}} flag which does exactly what {{{--make}}} does. I need to figure out the subsequent parts. One idea is that {{{hi}}} and {{{o}}} files will be deleted only if target directories are not specified using {{{-odir}}} and {{{-hidir}}} (since the target directories could be {{{/dev/null}}}). In this case these files are put in the same directory with the same name as the source file, and will be deleted. Other generated files from {{{-keep-*-files}}} will be preserved. So running with {{{ghc --cleanup}}} will, in effect, only create executables, and possibly some intermediate files other than {{{hi}}} and {{{o}}}. Is this a good idea? Also, have I missed something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 15:47:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 15:47:03 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.48872d9e6dd5f834f5b5b90f370bc4ba@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1728 Wiki Page: | -------------------------------------+---------------------------------- Comment (by bgamari): Here is an excerpt from the Diff description, > The gist here is that previously we didn't catch the case where a relocation > resulted in a jump that would overflow the 24-bit target address of ARM's > branch instructions. This resulted in a segmentation fault. I've added an > explicit check so that we now provide a reasonable error message in this case. > > Moreover, we now set `USE_CONTIGUOUS_MMAP` on ARM, following the behavior of > PowerPC to avoid symbols being too far removed from their extras. > > While doing this, I took the opportunity to refactor relocation handling, > making it follow LLVM LLD's implementation more closely since the ARM ELF > specification is a bit unclear in some places and I believe the LLD > implementation is trustworthy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 15:55:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 15:55:53 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.66418ff1b724d85c0afe762e5284ae2b@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1728 Wiki Page: | -------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"d159a51bb0f26aa232432987e88499109002b3f7/ghc" d159a51b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d159a51bb0f26aa232432987e88499109002b3f7" Linker: ARM: Refactor relocation handling This refactors handling of R_ARM_CALL, R_ARM_JUMP24, R_ARM_MOVW_NC, and R_ARM_MOVT relocations to follow the LLVM LLD implementation. The "ELF for ARM" specification is (like most documents of this type, sadly) a bit vague in some areas, so it seems safest to follow the behavior of a trusted implementation like LLD, which is remarkable in its clarity.. Moreover, we now throw a proper error message when a jump to a symbol extra is out of range. This is great improvement over the previous behavior, which ended in a segfault. See #11340. Differential Revision: https://phabricator.haskell.org/D1728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 15:55:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 15:55:53 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.0f0c37c8b8001fba0abff09078c9e995@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1728 Wiki Page: | -------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"07d127ad23c7e6056471d218adcc8ec5119fac6c/ghc" 07d127ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07d127ad23c7e6056471d218adcc8ec5119fac6c" Linker: Use contiguous mmapping on ARM ARM has a 24-bit relative jump offset just like PowerPC. Ensure that symbols don't get too far from their symbol extras. See #11340. Differential Revision: https://phabricator.haskell.org/D1728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 15:59:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 15:59:57 -0000 Subject: [GHC] #11340: linker_unload test fails on ARM In-Reply-To: <046.a62213e25c1394c85d381cec278c08db@haskell.org> References: <046.a62213e25c1394c85d381cec278c08db@haskell.org> Message-ID: <061.51ebcd7d9d7678a4a7ffa1bf0551e85e@haskell.org> #11340: linker_unload test fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1728 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 16:00:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 16:00:38 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.ac8b99d0aa1aba17fc6cf3176e8ac754@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11205, #11289, #11294, #11295, #11296, #11297 => #11205, #11289, #11294, #11295, #11296, #11297, #11340 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 16:21:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 16:21:23 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.b0b3ec9bba5c05920ab04128007e84b9@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): Replying to [comment:4 jstolarek]: > I just fear that the check would not be trivial. I also think that in most cases GADT result type simply includes indexed type constructor and having to duplicate the indices will be painful. I agree with you here fully. Also, I hope there's ''never'' a case where where a GADT result type isn't an instance of the parent type (modulo type synonyms)?that would be strange indeed! > In such corner cases that you've demonstrated indices might be very hard (impossible?) to recover. But I think that's acceptable. Again, I wouldn't think there's ''any'' case in which you couldn't recover the type indices. The only case where `th-desugar`'s `expand` function [https://github.com/goldfirere/th- desugar/blob/60b78b2b423fcb6f8bcdd2f10fbe2ce79192982c/Language/Haskell/TH/Desugar/Expand.hs#L56 can choke] is with type families, but GHC doesn't attempt to expand type families in a GADT definition anyway, so there's nothing to worry about: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeFamilies -XGADTs ?> type family Id a where Id a = a ?> data Wat a where Wat :: a -> Id (Wat a) :4:18: Data constructor ?Wat? returns type ?Id (Wat a)? instead of an instance of its parent type ?Wat a? In the definition of data constructor ?Wat? In the data declaration for ?Wat? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 17:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 17:04:05 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.bcd7b2ba5bb8bd4e2aa2813a275abe2d@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 19:32:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 19:32:36 -0000 Subject: [GHC] #11280: getCurrentDirectory should raise better error string when cwd doesn't exist In-Reply-To: <045.4baa55fc0d14cd014b96f19ac9b41514@haskell.org> References: <045.4baa55fc0d14cd014b96f19ac9b41514@haskell.org> Message-ID: <060.87369a210806574b4486d3de06a46880@haskell.org> #11280: getCurrentDirectory should raise better error string when cwd doesn't exist -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: ? Component: | Version: 7.11 libraries/directory | Resolution: duplicate | 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 thomie): * status: new => closed * resolution: => duplicate Comment: Moved to the `directory` issue tracker: https://github.com/haskell/directory/issues/39 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 19:36:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 19:36:39 -0000 Subject: [GHC] #11288: Thread blocked indefinitely in a Mvar operation In-Reply-To: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> References: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> Message-ID: <060.181f772fff30aaf6deb2e1872941cf98@haskell.org> #11288: Thread blocked indefinitely in a Mvar operation -------------------------------------+------------------------------------- Reporter: ygor_2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 19:46:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 19:46:28 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.d94a9f4dcdc62d6e128b158b9a5dfe64@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 thomie): * cc: gridaphobe (added) * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 19:53:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 19:53:45 -0000 Subject: [GHC] #11297: CmmSwitchTest is broken on 32-bit platforms In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.444a8b7ee63b73fc36d6337cbcbeeda5@haskell.org> #11297: CmmSwitchTest is broken on 32-bit platforms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: bgamari => Comment: Unassigning, to make this ticket actually show up on the [wiki:Newcomers] page. @bgamari: please claim it back if you planned to work on this yourself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 20:26:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 20:26:27 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.8690a0c262c6e29b3c31cdd08873a529@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): There are two things going on here. 1. We intentionally changed the meaning of a bare `?loc :: CallStack` in 8.0 to not include its own location, only function calls are appended to the stack now. So the first example is expected behavior in 8.0. 2. In your second example, GHC infers a CallStack parameter for fooHelper, thus it's occurrence in the instance declaration is appended to the stack. Why does GHC infer a CallStack for the 2nd fooHelper and not the 1st? Because the monomorphism restriction applies in the 1st declaration and prevents GHC from inferring a qualified type for fooHelper. So both cases are expected given the current implementation, but the difference is a bit annoying. The new implementation of the CallStack solver that allows GHC to infer CallStack parameters is essential to fix a terrible bug in the 7.10.2 solver, but it might make sense to prevent inferring CallStacks for top- level binders. I didn't do this originally since it would add another special case to the solver, and I don't want to do that without good reason. I'm not sure whether this qualifies, it's just another case of the monomorphism restriction. On the other hand, in this case we get different runtime behavior instead of an ambiguous type error, and this is definitely worse.. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 20:28:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 20:28:34 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.e993a67a9d01b52c91f3a888922c4028@haskell.org> #11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature request | Status: new Priority: normal | Milestone: 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 alexvieth): * Attachment "character_kind.patch" added. An implementation of character kind -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 21:57:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 21:57:35 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.6a8d1cd1c414a626da60b5761c9be1d0@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Thanks for picking this up. Could you maybe try submitting your patches to [wiki:Phabricator], so the build bot can validate them. > A thing I find surprising is the first argument in updateWith.go, which seems to be totally unused. Is this the correct behavior? Maybe you could tell us? This code was added in 28cf2e004da0fc809ce9efff0802b125b3501e91 (#8158). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 22:01:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 22:01:23 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work In-Reply-To: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> References: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> Message-ID: <060.e9fb8b9d44d3bc2ca8dade3c703fee7b@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | 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: #9675 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T9675-max_bytes_used.png" added. Test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 22:01:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 22:01:23 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work In-Reply-To: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> References: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> Message-ID: <060.9c695c657d5b6d01debb7f5ad8b57058@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | 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: #9675 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T9675-max_bytes_used.png" removed. Try again -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 22:03:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 22:03:36 -0000 Subject: [GHC] #10927: IndexError: pop from empty list In-Reply-To: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> References: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> Message-ID: <060.4368fc8000c85a8cde8f98dda1325953@haskell.org> #10927: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: schwab | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: This is fixed (I tested it). @hvr downgraded Genshi to version 0.6 as per comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 22:37:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 22:37:27 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.a56370e353af36d7ee6e298518a068f3@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Look at `Note [Loading instances for wired-in things]` in `LoadIface`. You should call `checkWiredInTyCon` when (but only when) you are using `CallStack` but not ''mentioning'' it. A classic example is when you write {{{ f :: [a] -> [a] }}} The explicit list syntax `[a]` uses `listTyCon` but does not mention it explicitly. Ditto tuples. Hence the calls to `checkWiredInTyCon` in `TcHsType`. Ah! I see what is happening. * `tc198` uses `undefined`, which is wired-in. * But the type of `undefined` mentions `CallStack`. * In `tcImportDecl_maybe`, we check for wired-in things, and call `loadWiredInHomeInterface` -- but only if `needWiredInHomeInterface` is True. * `needWiredInHomeInterace` is False of Ids; and even if it were True, we'd load `undefined`'s home interface not `CallStack`'s. The reason for the `loadWiredInHomeInterface` stuff is really to get `instance` declarations. And I suppose that if we have a wired-in Id whose type is `Bool -> M.T`, then we perhaps ought to check that `M.T`'s home interface is loaded in case there are any instances for it which we might need. So one solution is to adapt the wired-in-Id case of `tcImportDecl_maybe` to call `checkWiredInTyCon` on any `TyCon`s in the Id's type. But in fact the reason we need the home interface is ''not'' because of instances but to get its fingerprint. And it does seem bizarre to me that the fingerprint of a wired-in thing appears in the interface file if thing itself does not. Can't we give all wired-in things a fingerprint of zero? After all, they are wired-in. If we change them we change the compiler, and there are many cases in which changing the compiler requires a clean rebuild. In this case the worst that could happen would be some missing recompilation, and that is also an issue when, for example, we change interface file format. So I say that for wired-in things * make `MkIface.mkHashFun` return zero for wired-in names * filter out wired-in names when constructing fingerprints That would solve this ticket. Technically there is still a potential problem with missing instances (see above) but in practice it doesn't occur, and closing that theoretical hole would take more code and slow down every compilation. Any other observations/thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 22:50:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 22:50:10 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.234bdc7c860724d259f19b2619caf015@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonpj): Is the user manual section about implicit call-stacks up to date? Does it mention that a bare `?loc::CallStack` makes an empty stack? Does it give the functions that work on call-stacks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 22:58:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 22:58:20 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.9aa580fd1a77d61ce38e697299ec06d7@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Rev(s): Phab:D211, Wiki Page: | Phab:D1615 -------------------------------------+------------------------------------- Comment (by simonpj): Ah well, GHC 8.0 implements the simpler quantification rules, and now just says {{{ T4426.hs:5:29: error: Not in scope: type variable `b' }}} which at least isn't misleading! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 3 23:22:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jan 2016 23:22:05 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields Message-ID: <049.6becc7f1facb1381b419a45f19851622@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It seems to me that GHC should be able to easily infer the types for the record updates in this simple example. Is there a reason that it is unable to infer the type currently? {{{ {-# LANGUAGE OverloadedLabels, DuplicateRecordFields #-} module C where main = do print aThing print bThing print (aThing { a = 5 } ) print (bThing { a = 5 } ) data B = B { a :: Int} deriving Show bThing = B 10 data A = A { a :: Int } deriving Show aThing = A 10 {- [1 of 1] Compiling C ( C.hs, C.o ) C.hs:7:10: error: ? Record update is ambiguous, and requires a type signature ? In the first argument of ?print?, namely ?(aThing {a = 5})? In a stmt of a 'do' block: print (aThing {a = 5}) In the expression: do { print aThing; print bThing; print (aThing {a = 5}); print (bThing {a = 5}) } -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 00:38:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 00:38:41 -0000 Subject: [GHC] #10379: Prefix syntax for promoted list kind isn't parsed properly In-Reply-To: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> References: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> Message-ID: <060.1d9e97581c46ad1ad4dda508919ee8da@haskell.org> #10379: Prefix syntax for promoted list kind isn't parsed properly -------------------------------------+------------------------------------- Reporter: cactus | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | 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): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"1dbc8d91b7726a37c693fa769d19782871142b07/ghc" 1dbc8d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1dbc8d91b7726a37c693fa769d19782871142b07" Add test for #10379 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 00:41:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 00:41:16 -0000 Subject: [GHC] #10379: Prefix syntax for promoted list kind isn't parsed properly In-Reply-To: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> References: <045.b665c9274d3bfc113f143b054c4e84e6@haskell.org> Message-ID: <060.c293acf70320f9035301634d5ea1f34d@haskell.org> #10379: Prefix syntax for promoted list kind isn't parsed properly -------------------------------------+------------------------------------- Reporter: cactus | Owner: goldfire Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T10379 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => parser/should_compile/T10379 * status: new => closed * resolution: => fixed Comment: Fixed in commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2: {{{ Author: Richard Eisenberg Date: Fri Dec 11 18:19:53 2015 -0500 Add kind equalities to GHC. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 01:19:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 01:19:51 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.3152da6ae9f127f7cac858aa8a948885@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Rev(s): Phab:D638 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * status: infoneeded => new * milestone: 8.0.1 => 8.2.1 Comment: This clearly won't happen for 8.0. Perhaps we'll have better luck for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 01:24:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 01:24:48 -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.1a56fa98377255a5d7e8f32ee2dd43a2@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.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 bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: I intend on looking into this but it doesn't that anything will happen for 8.0 and indeed it's not terribly high priority given that GHC's `-j` option isn't very widely used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 01:30:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 01:30:00 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build In-Reply-To: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> References: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> Message-ID: <059.d1bd5c938cded1eac05e19aa47760e6c@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 01:35:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 01:35:26 -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.907c1ea4adc20cab01c1d7815664260c@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by nh2): {{{ given that GHC's -j option isn't very widely used }}} I think it's only not used so widely because it doesn't work well yet due to this bug - I have worked on 3 projects of 3 companies that would significantly benefit from it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 02:20:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 02:20:31 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.2b3a91d0616de7205edb38589d5370f1@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.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 ezyang): Hello all, I was recently looking at the Cabal code which is responsible for setting `hpcdir`, and I am a little confused by this ticket: why is it NOT sufficient to just specify different hpc directories for each main module? Does this have to do with wanting to combine tix files together? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 02:21:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 02:21:18 -0000 Subject: [GHC] #11344: Rule "and/build" not firing Message-ID: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> #11344: Rule "and/build" not firing -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- For this function {{{ isprime_1 :: Int -> Bool isprime_1 n = n >= 2 && ( and $ map (\t -> 0 < mod n t) $ [2 .. truncate $ sqrt $ fromIntegral n] ) }}} rule "and/build" is not firing with ghc-7.10.3. ghc-7.8.4 does fire the rule and produces much better (that is, non- allocating) code. I can get good code with 7.10 if I replace "and" by {{{ import GHC.Base (build) {-# RULES "und/build" forall (g::forall b.(Bool->b->b)->b->b) . und (build g) = g (&&) True #-} {-# NOINLINE und #-} und :: [Bool] -> Bool und = foldr (&&) True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 02:42:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 02:42:16 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken Message-ID: <050.9f334c84b36879f857088cd172154790@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | 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: -------------------------------------+------------------------------------- There are several infelicities in the way that Template Haskell treats GADT constructors that are declared to be infix. To illustrate: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} module Main (main) where import Language.Haskell.TH infixr 7 :***: data GADT a where Prefix :: Int -> Int -> GADT Int (:***:) :: Int -> Int -> GADT Int $(return []) main :: IO () main = do putStrLn $(reify ''GADT >>= stringE . pprint) putStrLn "" putStrLn $(reify ''GADT >>= stringE . show) }}} This doesn't print out quite what you'd expect: {{{ data Main.GADT (a_0 :: *) = Main.Prefix :: GHC.Types.Int -> GHC.Types.Int -> Main.GADT GHC.Types.Int | GHC.Types.Int Main.:***: GHC.Types.Int TyConI (DataD [] Main.GADT [KindedTV a_1627394505 StarT] Nothing [GadtC [Main.Prefix] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int),(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)] Main.GADT [ConT GHC.Types.Int],InfixC (Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int) Main.:***: (Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)] []) }}} TH thinks that `GADT` is a Haskell98 data declaration when `pprint`-ing it because `(:***:)` is converted to an `InfixC` (see [http://git.haskell.org/ghc.git/blob/04f3524f787b2cbd3f460e058c753529d3f2f7ac:/libraries /template-haskell/Language/Haskell/TH/Ppr.hs#l362 here] for the relevant code). This causes the output to be a strange hodgepodge of Haskell98 and GADT syntax. Another issue is that even though I can reify `GADT`, I can't splice it back in! Compiling this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} module Main (main) where import Language.Haskell.TH $(do gadtName <- newName "GADT" prefixName <- newName "Prefix" infixName <- newName ":***:" a <- newName "a" return [DataD [] gadtName [KindedTV a StarT] Nothing [GadtC [prefixName] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int),(Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int)] gadtName [ConT ''Int],InfixC (Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int) infixName (Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int)] []]) $(return []) main :: IO () main = do putStrLn $(reify ''GADT >>= stringE . pprint) putStrLn "" putStrLn $(reify ''GADT >>= stringE . show) }}} Results in an error: {{{ InfixGADT.hs:12:3: error: Cannot mix GADT constructors with Haskell 98 constructors When splicing a TH declaration: data GADT_0 (a_1 :: *) = Prefix_2 :: GHC.Types.Int -> GHC.Types.Int -> GADT_0 GHC.Types.Int | GHC.Types.Int :***:_3 GHC.Types.Int }}} [http://git.haskell.org/ghc.git/blob/04f3524f787b2cbd3f460e058c753529d3f2f7ac:/compiler/hsSyn/Convert.hs#l191 This code] is responsible. We have an issue where `InfixC` can be either Haskell98 or GADT syntax depending on the context, but in that particular context, there's not a good way to determine it. I can think of three solutions: 1. Add an `InfixGadtC` constructor. This adds more clutter to `Con`, but is the most straightforward fix. 2. Subsume infix GADT constructors under `GadtC`/`RecGadtC` (depending on if it has records), and treat `InfixC` as always being Haskell98. This wouldn't require any API changes, but it does leave a bit of asymmetry between the Haskell98 and GADT constructors, since there would be three of the former but two of the latter. 3. A radical approach (which subsumes option 2) would be to deprecate `InfixC`, subsume it under `NormalC`/`RecC`, and add an `InfixC` pattern synonym for compatibility. `InfixC` does seem extraneous anyway since you can just use `reifyFixity` to determine if a constructor is infix. That way, you have two Haskell98 and two GADT constructors (but you'd also have to deprecate `InfixC`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 03:36:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 03:36:24 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.e978b47a7319fc877adc8eb19e2c7011@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.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 mgsloan): There's a pretty good reason not to vary `--hpcdir`. You can only pass in one `--hpcdir` to the `hpc` program, and it's treated as a relative path to each of the `--srdir`s. So, if you want to generate a report which spans multiple packages, `--hpcdir` needs to be kept constant. We might consider improving the hpc program's CLI. This particular issue is discussed further in https://ghc.haskell.org/trac/ghc/ticket/10951 The tricky thing about combining tix files together is that module names within the tix file are not sufficiently disambiguated. For packages, they are prefixed by their package key / id. So, you expect to find the mix file for `TixModule "cycli_6S2W1a0WjTe91AyXmPMq2j/Cyclic" ...` at some `HPCDIR/cycli_6S2W1a0WjTe91AyXmPMq2j/Cyclic.mix`. However, for modules from the non-library components, there is no folder. Instead it's just `TixModule "Main" ...` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 04:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 04:03:57 -0000 Subject: [GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' In-Reply-To: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> References: <042.69f8f35bf900f4761f4e8a16c57f4818@haskell.org> Message-ID: <057.1fc0776d521a17652d6757c4067da3b1@haskell.org> #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: attached Blocked By: | Blocking: Related Tickets: #437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rimmington): * cc: rimmington (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 04:06:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 04:06:08 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.9810faa6a28a90c9078dfe847c10e8d7@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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 goldfire): This is truly bizarre. Here are a few things I've learned: 1. The module compiles with `-XNoMonomorphismRestriction`. This is actually correct behavior. The issue is that the inferred type of `t` is quantified (by `Applicative f`). The monomorphism restriction forbids this. So the new behavior is correct, I think. 2. Sadly, adding `t :: Applicative f => (a -> f b) -> f t`, by itself, doesn't fix the problem 3. The line that you say doesn't compile does indeed compile if you add `t :: Applicative f => (a -> f b) -> f t` 4. The line that you say doesn't compile does indeed compile if you add `-XMonoLocalBinds`. 5. Saying `t :: _` emits no warning. I have no idea why. Here is some interpretation of the above: A. Fact (2) is a consequence of the fact that GHC considers itself to be inferring a type for all pattern bindings, even if there is a complete type signature. (See `TcBinds.decideGeneralisationPlan`) I don't know why this is the case; I did not change this behavior. Visible type application does a little extra jiggery pokery when inferring types. See `Note [Instantiate when inferring a type]` in !TcBinds. This jiggery pokery is triggered because we're inferring the type of `t`, even when a type signature is given. B. Facts (3) and (4) (really the fact that the commented line doesn't compile in the first place) is because we're in the quite rare scenario where `-XMonLocalBinds` is a good idea, even absent type families / GADTs. This is not the first such example, but I don't have a link to a previous one. Perhaps `RankNTypes` should imply `MonoLocalBinds`. Bottom line: The only real bug in here is (2). It really should compile with the type signature, regardless of the monomorphism restriction. But it doesn't. However, the example as submitted should be rejected, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 04:17:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 04:17:05 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.b73871fc5f51650c0e4567d758027da3@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Replying to [comment:4 gridaphobe]: > (By the way, how ''did'' you figure out what was triggering the load?) Erm... I used this brand new feature called implicit call stacks to trace back who was making the calls to load `GHC.Stack.Types` in the successful case. It's a bit odd how useful the feature was in debugging its own implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 09:11:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 09:11:05 -0000 Subject: [GHC] #11344: Rule "and/build" not firing In-Reply-To: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> References: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> Message-ID: <064.5f886e8f7efdac768c50c312b9f1c578@haskell.org> #11344: Rule "and/build" not firing -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9848 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate * related: => #9848 Comment: This is a regression due to BBP: `and` no longer is `GHC.OldList.and` (if you import that, it works), but rather {{{ and :: Foldable t => t Bool -> Bool and = getAll #. foldMap All }}} `foldMap` has been modified to fuse better since then, see #9848. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 09:11:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 09:11:26 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.28ffc60da112c633b13291c3372ef355@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As of 04f3524f787b2cbd3f460e058c753529d3f2f7ac we have, {{{ Unexpected results from: TEST="barton-mangler-bug cabal03 ghci004 ghci006 outofmem recomp011 cabal01 prog001 T10359 T9203 T7257 lazy-bs-alloc T5321FD T5030 T4801 T5631 T5837 T9872a T9872d T9872b T3064 T9872c T1969 T5321Fun T783 T9233 T9961 haddock.Cabal haddock.compiler haddock.base" OVERALL SUMMARY for test run started at Mon Jan 4 02:12:40 2016 CET 4:11:39 spent to go through 4963 total tests, which gave rise to 15727 test cases, of which 10813 were skipped 72 had missing libraries 4704 expected passes 108 expected failures 1 caused framework failures 0 unexpected passes 8 unexpected failures 22 unexpected stat failures Unexpected failures: cabal/cabal01 cabal01 [bad exit code] (normal) cabal/cabal03 cabal03 [bad exit code] (normal) driver/recomp011 recomp011 [bad stdout] (normal) ghci/prog001 prog001 [bad exit code] (ghci-ext) ghci/scripts ghci004 [bad exit code] (ghci-ext) ghci/scripts ghci006 [bad exit code] (ghci-ext) programs/barton-mangler-bug barton-mangler-bug [exit code non-0] (normal) rts outofmem [bad stdout] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 09:11:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 09:11:36 -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.35a05bcc100adf4f60ff6c131ec99285@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by slyfox): Don't know about other users but starting from ghc-7.8 every gentoo packages are built with -j4 on machines with enough CPU cores. Thinking about building initial ghc-cabal for GHC build in parallel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 09:31:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 09:31:35 -0000 Subject: [GHC] #10737: GHC panic durring MVar operation In-Reply-To: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> References: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> Message-ID: <064.7375153576b90af8eb0b3f4c089f301e@haskell.org> #10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #4245, #9940 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rdragon): * related: #4245 => #4245, #9940 Comment: Replying to [comment:1 thomie]: > Might be the same underlying cause as #4245, although that ticket deals mostly with control-C in GHCi on Windows and Mac resulting in the same error message. Looks like Ctrl-C is also at play here, judging the `Interrupted` message above the `:r` command. This would also explain why dohaqatar7 was not able to reproduce the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 09:44:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 09:44:29 -0000 Subject: [GHC] #11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic In-Reply-To: <047.29ed0108e386c108bb8327899f548be4@haskell.org> References: <047.29ed0108e386c108bb8327899f548be4@haskell.org> Message-ID: <062.87537c1ef8526e7613d036b0790db806@haskell.org> #11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic ---------------------------------+---------------------------------------- Reporter: cwfenner | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: GHCi | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9940 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by rdragon): * status: new => closed * resolution: => duplicate * related: => #9940 Comment: Thanks for the ticket and your description about how to reproduce the crash. However, as this issue was already reported in #9940 I will flag this ticket as duplicate and point from #9940 to here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 09:45:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 09:45:57 -0000 Subject: [GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. In-Reply-To: <045.57a3cba5fea4ade3aa4122b02fda65ee@haskell.org> References: <045.57a3cba5fea4ade3aa4122b02fda65ee@haskell.org> Message-ID: <060.fcd74455ed42e572c430f5ac4cd14473@haskell.org> #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------+------------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: crash, | control-c Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #4245, #10737, | Differential Rev(s): #11175 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rdragon): * related: => #4245, #10737, #11175 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 10:19:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 10:19:06 -0000 Subject: [GHC] #10737: GHC panic durring MVar operation In-Reply-To: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> References: <049.580b198cd1c514601e30fc759ca3d8fa@haskell.org> Message-ID: <064.0b2cf5c9a35e51e7932a583012784fb7@haskell.org> #10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #4245, #9940 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Replying to [comment:3 rdragon]: > Looks like Ctrl-C is also at play here, judging the `Interrupted` message above the `:r` command. This would also explain why dohaqatar7 was not able to reproduce the crash. Ah, you're right. Let's close this one as a duplicate of #9940 as well then. Thanks for reporting, dohaqatar7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 10:46:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 10:46:48 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.1811afc1b15832610d7c6884bbfdbe44@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): * priority: normal => high * version: 7.10.3 => 7.11 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 11:23:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 11:23:40 -0000 Subject: [GHC] #11346: GHCi can crash when tabbing a filename Message-ID: <045.bea937f4240737f03707082c605dbcc2@haskell.org> #11346: GHCi can crash when tabbing a filename ------------------------------+------------------------------- Reporter: honnza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- The following sequence of actions: 1. Type `:: I` into GHCI 2. Press the tab key 3. Hold backspace to erase the resulting text 4. Repeat steps 2 and 3 May result in the following appearing in the console: {{{ Prelude Data.Map> :: ImageExpo.config ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): Prelude.chr: bad argument: (-947713851) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} followed by the system prompt. Afterwards I have realised that `::` was actually interpreted as a GHCi command rather than the type designation syntax. Tabbing yields all files in the current directory, but actually performing the command yields `unknown command '::'` There is only one file that starts with `I` in my current directory. Did not manage to reproduce -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 11:39:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 11:39:42 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.f5d8b89a6d95187c14010c5592ec7e65@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 adamgundry): * owner: => adamgundry * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) * version: 7.10.3 => 7.11 * type: bug => feature request Comment: By design, we don't do any inference to determine which record type is meant in this kind of situation. Instead, the type must be pushed in to the update, or the record expression being updated must have a type signature. Thus either of these should work: {{{#!hs print (aThing { a = 5 } :: A) print ((bThing :: B) { a = 5 } ) }}} I suppose we could add a special case for when the record expression is a variable whose type is known, which would cover this example. I'm not sure if it's a good idea to accumulate too many special cases, but perhaps this case is common enough that it's worthwhile? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 14:05:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 14:05:22 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.7f1cd24c29cda0f6b98bcc9a47cd85b4@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > Also, have I missed something? Maybe. Check out: * -dynamic * -dynamic-too * -dyno * -dynosuf * Should intermediate files also get deleted when using `--cleanup` to create shared libraries (https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/using- shared-libs.html)? * What happens on compilation failures. Say `A.hs` contains a syntax error, and imports `B.hs`. When running `ghc --cleanup A.hs`, `B.hs` gets compiled first, creating `B.hi` and `B.o`. Then `A.hs` fails to compile, because of the syntax error. Should `B.hi` and `B.o` get deleted? * Is `ghc --make --cleanup` allowed? Maybe the command line interface should be something like `ghc --make -cleanup` (so `-cleanup` would not be a mode flag, but a regular flag, just like for example `-keep-tmp-files` and `-outputdir`.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 15:23:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 15:23:33 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.0d41d89d785367a5502e5e6fc34b7b12@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D646 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Too bad this did not make it into 7.10.3. The bug happens when trying out the code that explains how to derive `unsafeCoerce` from GND+TypeFamilies if we had not roles. (This comment has little nutritional content.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 15:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 15:28:55 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] Message-ID: <046.e27f7055787d51e2a672587abfd14828@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 was testing this code, which is from our ICFP paper on Coercible: {{{#!hs {-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving, MultiParamTypeClasses, FlexibleInstances, AllowAmbiguousTypes #-} newtype Id1 a = MkId1 a newtype Id2 a = MkId2 (Id1 a) deriving (UnsafeCast b) type family Discern a b type instance Discern (Id1 a) b = a type instance Discern (Id2 a) b = b class UnsafeCast to from where unsafe :: from -> Discern from to instance UnsafeCast b (Id1 a) where unsafe (MkId1 x) = x unsafeCoerce :: a -> b unsafeCoerce x = unsafe (MkId2 (MkId1 x)) }}} without `AllowAmbiguousTypes` I get {{{ UnsafeCast.hs:11:3: error: Couldn't match type ?Discern from to0? with ?Discern from to? NB: ?Discern? is a type function, and may not be injective The type variable ?to0? is ambiguous Expected type: from -> Discern from to Actual type: from -> Discern from to0 In the ambiguity check for the type signature for ?unsafe?: unsafe :: forall to from. UnsafeCast to from => from -> Discern from to To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: unsafe :: forall to from. UnsafeCast to from => from -> Discern from to In the class declaration for ?UnsafeCast? }}} (is that a bug? I feel like it could be, but I?m intimidated by the error message). So I put in the suggested pragma, and now I get {{{ UnsafeCast.hs:4:41: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151111 for x86_64-unknown-linux): No skolem info: b_azg[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is GHC-almost-HEAD (changeset:2f6e87/ghc). I?ll start a rebuild with head and see what has changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 15:35:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 15:35:50 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.622a9c8362fcec53a5e70b2a6a10ee85@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10946, #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #10946, #10045 Comment: Other tickets with this error message: #10946, #10045 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:18:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:18:52 -0000 Subject: [GHC] #11314: Documentation on const function is wrong In-Reply-To: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> References: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> Message-ID: <066.0d6187ddc70d73e9cb0b664c0b91301f@haskell.org> #11314: Documentation on const function is wrong -------------------------------------+------------------------------------- Reporter: milleniumbug | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.3 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:D1720 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"da0f04305d7bdc172f7a7a7b73f171b83acca87f/ghc" da0f043/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da0f04305d7bdc172f7a7a7b73f171b83acca87f" Rewrite Haddocks for GHC.Base.const Test Plan: Read it Reviewers: austin, hvr, #core_libraries_committee Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1720 GHC Trac Issues: #11314 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:42:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:42:11 -0000 Subject: [GHC] #2595: Implement record update for existential and GADT data types In-Reply-To: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> References: <046.4aca36ddfd3abd8f80e6714ed9319183@haskell.org> Message-ID: <061.c1b90802fe2a4681f4f23758ebe46943@haskell.org> #2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tc244 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adam.gundry@? (removed) * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:43:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:43:59 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.57b0fdfc8ceb630c4ba3a9a859b4ee87@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: records 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: adam.gundry@? (removed) * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:44:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:44:51 -0000 Subject: [GHC] #7169: Warning for incomplete record field label used as function In-Reply-To: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> References: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> Message-ID: <062.25ffbe74e8ef451c25e556ccf629d16f@haskell.org> #7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | 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 adamgundry): * cc: adam.gundry@? (removed) * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:46:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:46:36 -0000 Subject: [GHC] #4479: Implement Dot as Postfix Function Apply In-Reply-To: <044.f4d93903ed5f63cdd9805deaee3ed98d@haskell.org> References: <044.f4d93903ed5f63cdd9805deaee3ed98d@haskell.org> Message-ID: <059.ae8aa0cae9f4ffa37d0ecac5ef0ad4ad@haskell.org> #4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.5 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 adamgundry): * cc: adam.gundry@? (removed) * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:50:27 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi In-Reply-To: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> References: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> Message-ID: <057.e95eba2576e4bdc8832e0bd092bded04@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.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:D1240 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:52:06 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.1ade289c87f0ea25f88fd681cc75f48c@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:53:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:53:26 -0000 Subject: [GHC] #11268: Extend ghc environment file features In-Reply-To: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> References: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> Message-ID: <057.f46a78df657e2f435deadee4f1db5e4d@haskell.org> #11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: duncan Type: feature request | Status: patch Priority: highest | Milestone: 8.0.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:D1668 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => duncan Comment: Ceding this to Duncan as it's his patch and he has returned from vacation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 16:57:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 16:57:19 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.def44ec0b1622818b90bd524b5c25f40@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): When quickly reviewing Phab:D1656 in response to some validation issues I noticed that these `exprIsTrivial` variants differ slightly in their treatment of literals. While `CorePrep`'s `cpe_ExprIsTrivial` always considers `Lits` to be trivial, `CoreUtils`'s variant relies on `Literal.litIsTrivial` in this case. `litIsTrivial` deems all literals except `MachStr` and `LitIntegers` to be trivial. This effectively means that `cpeArg` will no longer consider these literals to be trivial, resulting in eta expansion of some expressions containing them which are currently left untouched. This is evidently problematic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 17:05:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 17:05:53 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.4197bbd1e4620e90dad3f1abb547498d@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gkaracha): To wrap up, do we all agree that the warning should be suppressed by default? If yes, let me know so that I can fix it soon, one less ticket to worry about :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 18:53:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 18:53:49 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking Message-ID: <048.419b44d406ca8091f032a727fdd29058@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeInType #-} import Data.Kind import Data.Proxy type family TrivialFamily t :: Type type instance TrivialFamily (t :: Type) = Bool data R where R :: Proxy Bool -> R type ProblemType t = 'R ('Proxy :: Proxy (TrivialFamily t)) }}} Compiling this program as-is, GHC rejects it! {{{#!sh error: ? Expected kind ?Proxy Bool?, but ?'Proxy? has kind ?Proxy (TrivialFamily t)? ? In the first argument of ?R?, namely ?(Proxy :: Proxy (TrivialFamily t))? In the type ?R (Proxy :: Proxy (TrivialFamily t))? In the type declaration for ?ProblemType? }}} But if we move `TrivialFamily` to another module and import it, GHC discovers that `TrivialFamily t = Bool` and the program is accepted. When compiling the rejected program (with the local family instance) I observe that the instance environments given by `FamInst.tcGetFamInstEnvs` contain no instances! The renamer processes the local instance, but no `FamInst` is created for it, and nothing enters the `TcGblEnv`'s family instance record. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 19:29:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 19:29:22 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base Message-ID: <051.287da149b49626768faa704af8139943@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base ----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Keywords: TypeApplications | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Now that we have [https://phabricator.haskell.org/D1138 TypeApplications] how about we create a Proxy-free version of functions in base that currently require it: {{{#!hs tr :: forall a. Typeable a => TypeRep tr = typeRep @Proxy @a Proxy symbol :: forall s. KnownSymbol s => String symbol = symbolVal @s Proxy nat :: forall n. KnownNat n => Integer nat = natVal @n Proxy }}} While we're at it let's use [https://hackage.haskell.org/package/base/docs /Numeric-Natural.html Natural] as the value-level representation of Nat, avoiding `Maybe` in `someNatVal :: Integer -> Maybe SomeNat`: {{{#!hs nat :: forall n. KnownNat n => Natural nat = natVal @n Proxy someNatVal :: Natural -> SomeNat someNatVal = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 19:43:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 19:43:20 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.21647068111db5e5008ae8c36cf874aa@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `sizeof` and other `Storable` methods come to mind too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 19:59:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 19:59:54 -0000 Subject: [GHC] #11350: Allow visible type application in patterns Message-ID: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructors (and pattern synonyms) when treated as expressions may be applied to types: {{{#!hs {-# LANGUAGE TypeApplications #-} Nothing :: Maybe a Nothing @() :: Maybe () pattern Pair :: a -> a -> (a, a) pattern Pair x y = (x, y) Pair :: a -> a -> (a, a) Pair @Int :: Int -> Int -> (Int, Int) }}} But using them in patterns won't parse: {{{#!hs -- parse error in pattern: @Int maybeToList :: Maybe Int -> [Int] maybeToList (Nothing @Int) = [] maybeToList (Just @Int x) = [x] -- parse error in pattern: @Int add :: (Int, Int) -> Int add (Pair @Int x y) = x + y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 20:01:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 20:01:40 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.b69ac84f1acf9d0b50ca0064ff4f68fd@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0acdcf2482d24903b504e6b34fa745ef855ff00d/ghc" 0acdcf24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0acdcf2482d24903b504e6b34fa745ef855ff00d" Avoid generating guards for CoPats if possible (Addresses #11276) When translating a `CoPat` to `PmPat` check whether the wrapper is just a hole or a cast with refl. In these cases we can safely drop the wrapper and generate less guard patterns. Fixes T11276. Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1729 GHC Trac Issues: #11276 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 20:10:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 20:10:35 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms Message-ID: <051.f6994676afcea2faaae7090f3210796a@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- Unsure of pattern synonym scoping rules. I want to be able to refer to a type in the signature (assuming `symbol` from #11349): {{{#!hs symbol :: forall s. KnownSymbol s => String symbol = symbolVal @s Proxy -- Not in scope: type variable ?s? -- Not in scope: type variable ?s? pattern Symbol :: forall s. KnownSymbol s => String pattern Symbol <- ((== symbol @s) -> True) where Symbol = symbol @s }}} Without `TypeApplications`: {{{#!hs -- ? Could not deduce (KnownSymbol n0) -- arising from a use of ?symbolVal? -- from the context: KnownSymbol s -- bound by the type signature for pattern synonym ?Symbol?: -- String pattern Symbol :: forall s. KnownSymbol s => String pattern Symbol <- ((== symbolVal (Proxy :: Proxy s)) -> True) }}} but it (GHCi, version 8.1.20160102) says the type variable `s` is not in scope. The desired outcome would be something like (this touches on ticket #11350): {{{#!hs >>> Symbol @"blessed duck" "blessed duck" isDuck :: String -> Bool isDuck (Symbol @"duck") = True isDuck _ = False }}} With a nudge and a wink to #9671. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 20:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 20:16:49 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.91ec18a7a6b24c65ddc440bdf5cc9ebd@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by gkaracha): Herbert, could you check again whether `text-icu` can be built with the current HEAD? My patch for #11276 has been merged so I expect `text-icu` to be built normally. If so, please also revert #11303 to closed. Thanks for the help! :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 20:28:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 20:28:57 -0000 Subject: [GHC] #11352: Allow applying type to label Message-ID: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> #11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE OverloadedLabels #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE DataKinds #-} import GHC.TypeLits import GHC.OverloadedLabels instance IsLabel "answer" Int where fromLabel _ = 42 answer :: IsLabel "answer" a => a answer = #answer }}} The follow works: {{{#!hs >>> answer @Int 42 }}} but fails with a label: {{{#!hs >>> #answer @Int :...:1: error: ? Cannot not apply expression of type ?t0? to a visible type argument ?Int? ? In the expression: #answer @Int In an equation for ?it?: it = #answer @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 20:52:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 20:52:02 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.5fd0781a53483f0c9975eec883c387a8@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): Thanks for the explanation Simon. I agree with your proposal re wired-in things, I'll send a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 21:12:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 21:12:25 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.d3f6d159666b9aaa1601990d8833efb1@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): I updated the user guide as part of the rewrite, the current version is hosted [http://downloads.haskell.org/~ghc/master/users- guide//glasgow_exts.html#implicit-callstacks here]. It does mention that a bare `?loc :: CallStack` will be resolved to the empty stack ("GHC will never report an unbound implicit CallStack, and will instead default such occurrences to the empty CallStack.") It also describes `getCallStack` for extracting the list of call-sites, and `freezeCallStack` for preventing the addition of further call-sites. There are a couple other API functions (`push` and `pop`) that are only mentioned in the haddocks, but I think that's ok as they're pretty self- explanatory. Ack, I just noticed that the formatting is a bit screwy towards the end of the section, I'll send a patch to clean it up. If you have any comments/suggestions on the content itself I'd be happy to incorporate them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 21:22:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 21:22:14 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls Message-ID: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Unsafe foreign calls result in adjustments to `$rsp` made in the NCG to comply with calling convention alignment requirements (see `X86.CodeGen.genCCall64'`). Unfortunately, this happens after we've generated unwind information. This results in incorrect unwinding information for `$rsp` when inside of a foreign call. The results can be quite catastrophic (e.g. segmentation faults while unwinding). Unfortunately it's really not clear what can be done about this given that these adjustments aren't present in the Cmm representation that we use to produce frame information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 21:25:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 21:25:05 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.7730f758af695478bab40001ca9725eb@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Perhaps we can feed the `DebugBlocks` as state into the NCG. The NCG can then make the appropriate updates before finally producing the final debug information? Ugh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 21:39:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 21:39:10 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.484171aad85f06deb8ef6fbdd9d5217e@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In fact, it looks like the NCG already has read-only access to the `DebugBlock`s. Perhaps this idea isn't so crazy. The tricky part is ensuring that the debug entries remain properly sorted. Perhaps you could say something like "insert this `UnwindTable` after label `c2TN`"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 22:52:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 22:52:48 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.e3f99d27ac5ef432378093abddaf99f8@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, for some reason, this program still seems to be blowing up GHC even with the latest changes: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Slow where data family Letter a data instance Letter a = A | B | C | D | E | F | G | H | I | J f :: [Letter a] -> Int f = foldl go 0 where go n letter = n + n' where n' = case letter of A -> 0 B -> 1 C -> 2 D -> 3 E -> 4 F -> 5 G -> 6 H -> 7 I -> 8 J -> 9 }}} This time, adding explicit type signatures to `go` and/or `n'` does ''not'' make it work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 22:53:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 22:53:06 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.f3d05bfc49d3a821e62494f4b39eadb6@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It turns out that the ghci issues were merely due to `iserv` being out of date. Rebuilding seems to fix these, resulting in, {{{ Unexpected results from: TEST="outofmem recomp011 T10359 T9203 T7257 lazy-bs-alloc T5321FD T5030 T4801 T5631 T5837 T9872a T9872d T9872b T3064 T9872c T1969 T5321Fun T783 T9233 T9961 haddock.Cabal haddock.compiler haddock.base" OVERALL SUMMARY for test run started at Mon Jan 4 23:43:35 2016 CET 0:09:07 spent to go through 30 total tests, which gave rise to 85 test cases, of which 52 were skipped 0 had missing libraries 9 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 2 unexpected failures 22 unexpected stat failures Unexpected failures: driver/recomp011 recomp011 [bad stdout] (normal) rts outofmem [bad stdout] (normal) }}} Check and mate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 4 23:21:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jan 2016 23:21:55 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.ecefef1ad49fdcee5cca9966afee52a3@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Another option along these lines would be to abandon tracking label ordering at all until code generation. Then the code generator could modify the `DebugBlock` to its hearts content, so long as in the end it returned the unwinding tables in the proper order. For those playing along at home, the issue here is that DWARF requires that frame unwinding tables (FDEs) must be written in order of increasing address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 00:31:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 00:31:53 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.5148f72447ea9fe8b5659a876edbaacf@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): * Attachment "0002-Fix-11348-collect-module-local-family-instances.patch" added. A potential fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 02:53:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 02:53:00 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix Message-ID: <043.018901061c911df7ad296ca4936d7024@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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 potentially bad when multiple GHC versions are installed - last installed one overwrites all the docs. It seems like docs are installed under {{{$PACKAGE_TARNAME}}}, and tarname is initialized as {{{"ghc"}}} in the {{{ac}}} file. I guess one solution would be to add version suffix to tarname (it seems like tarname is only used when installing docs) or alternatively use {{{${PACKAGE_TARNAME}-${PACKAGE_VERSION}}}} to install docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 02:54:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 02:54:00 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.f668c07077500523eaa4af1ebfe1f6bf@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms 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 Iceland_jack): Relevant note on [https://github.com/ghc/ghc/commit/2db18b8135335da2da9918b722699df684097be9 #diff-b0c0b2c93d6cc4f591c913d42daa7b2eR518 ?Lexing type applications?] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 03:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 03:26:15 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.1c00968ae047dbedeb9a108e6f444be8@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): Currently, we kind- and type-check `TyClGroup`s before we even consider any family instances. I suppose this is ok without `TypeInType`, where the kind of a type cannot depend upon a family instance. But with it, seems we have to check our `TyClGroup`s in tandem with our family instances! So the title of this ticket isn't so accurate; they're not ignored, they're just not considered until it's too late. The patch is no good. I believe I now understand the problem and I'm working on another patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 03:54:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 03:54:31 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.27351e44756b29da145ba6eb0933a8b4@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 goldfire): Yay yay yay. Thanks! The issue here is a known infelicity, but it seemed to me that fixing it would take a fair amount of reinstallation of plumbing. I think you'll have to type-check instance declarations (the first of the two passes in !TcInstDcls) in with mutually recursive groups. A type whose kind mentions an open type family depends on the instances of that family. If you're up to this task, that would be wonderful. I'm more than happy to advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 08:01:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 08:01:44 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.bfab1c1d21c2574d4e3b8041b8f14a3c@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by gkaracha): Oh, yes, this is rather expected. I added a note in `deSugar/Check.hs` about the general case: `Note [Translate CoPats]`. As the note says, a `CoPat` is translated as follows: {{{ pat |> co ===> x (pat <- (x |> co)) }}} In the latest commit [changeset:"0acdcf2482d24903b504e6b34fa745ef855ff00d/ghc" 0acdcf24/ghc], I added two cases when translating `CoPat`s: * If `co` is refl we can drop it and do not generate the guard * If `co` is just a hole, we can also drop it. So, as the commit message says, we now generate **less** guards. For data families, this coercion is essential, because changes the representation tycon to the source tycon and I cannot drop it, that is, without changing the type of the pattern. The previous examples had `CoPat`s due to inference but your example above uses data families directly so the workaround does not apply. I can only hope that I will be able to come up with a better translation for `CoPat`s before the release but I do not know how to address this yet. Btw, I think we should move this whole discussion to #11276 since #11303 is rather irrelevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 09:34:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 09:34:15 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.351b27f941614a6edc06257be9f6e6f3@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 Ben Gamari ]: > In [changeset:"0acdcf2482d24903b504e6b34fa745ef855ff00d/ghc" 0acdcf24/ghc] Merged to ghc-8.0 via c1acc2a92947f512b1a6a20019524af09266a2aa -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 09:37:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 09:37:14 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.ad2e0162a81e5dd0ec379f26b3a130ac@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: Replying to [comment:15 gkaracha]: > Herbert, could you check again whether `text-icu` can be built with the current HEAD? > My patch for #11276 has been merged so I expect `text-icu` to be built normally. If so, > please also revert #11303 to closed. Thanks for the help! :-) I can confirm that `text-icu` now compiles with a more reasonable memory usage... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 09:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 09:50:46 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.a9e2f95302c74b4c0ce49bc5a235b368@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10946, #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Still in todays?s HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 09:56:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 09:56:41 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.8af170a6192889de060ca62aea380a6d@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10946, #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"1a8b752d8b03266aca3e83f79c311056d6c43e00/ghc" 1a8b752/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a8b752d8b03266aca3e83f79c311056d6c43e00" Add (failing) test case for #11347 Unfortunately, I could not add the expected error message, so if someone accidentally fixes this bug, this test will still be failing (no harm). But maybe someone stumbles over it then and can update the expected output. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 10:05:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 10:05:14 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.1a9469af5824529ca224ab7d5db7159c@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): Can someone explain the problem in more detail? Why should the instance declarations affect the kind of the type constructor? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 10:45:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 10:45:55 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.0d8857a1c0ffd79aa3c7f6dfde8a3743@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact 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 thomie): * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 10:50:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 10:50:01 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.749f1013aa9de716e6203f3c654a5dcf@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.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:D1205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 11:04:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 11:04:33 -0000 Subject: [GHC] #10579: full module names of names not in scope have gone missing in ghci In-Reply-To: <047.b63d248973b529e66515b0b0ffe3a663@haskell.org> References: <047.b63d248973b529e66515b0b0ffe3a663@haskell.org> Message-ID: <062.5ab59eb8c1cf83b478b13daacce73c6e@haskell.org> #10579: full module names of names not in scope have gone missing in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11208 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11208 Comment: Fixed in #11208. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 11:09:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 11:09:34 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.4ad5d95c3bcdb344459d9fc5464f0997@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 NeilMitchell): I agree that seems a minimum starting point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 11:14:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 11:14:03 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.b52456c8df5bd2d8d135680c2a5da72f@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: wontfix | 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 NeilMitchell): * cc: simonmar (added) Comment: That all makes sense. From my perspective, NonTermination and BlockedIndefinitelyOnMVar are separate analysis passes (which as an implementation detail you have implemented in one go), and when viewed that way, having the first analysis raise the exceptions first seems quite reasonable. For info, I have a workaround in my case - catch the blocked exception, sleep for a second, then retry and see if the MVar is now filled. It's ugly (particularly the 1s sleep), but it works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 11:20:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 11:20:39 -0000 Subject: [GHC] #10984: the ghc-7.8.4 source distribution contents (README, etc.) In-Reply-To: <048.ca5997b56646bcd8525b32248f39d0ec@haskell.org> References: <048.ca5997b56646bcd8525b32248f39d0ec@haskell.org> Message-ID: <063.e794357382e703fc24deb600ee2ebb62@haskell.org> #10984: the ghc-7.8.4 source distribution contents (README, etc.) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #9926 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9926 Comment: Thanks for the report. This was later fixed in #9926, but there won't be a 7.8.5 release unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 11:31:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 11:31:22 -0000 Subject: [GHC] #3140: (Windows?) GHCi doesn't load hierachical modules In-Reply-To: <044.2eb3a00ae65a21d331fc8637974706c7@haskell.org> References: <044.2eb3a00ae65a21d331fc8637974706c7@haskell.org> Message-ID: <059.1c93c0aea3db560dfbf38d0f69c187ed@haskell.org> #3140: (Windows?) GHCi doesn't load hierachical modules ------------------------------------+------------------------------ Reporter: Orphi | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 8.0.1 Component: GHCi | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10643 | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------ Changes (by thomie): * status: new => closed * failure: => None/Unknown * resolution: => duplicate * related: => #10643 Comment: This was brought up again recently in #10643, which has more discussion, so I'll close this one as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 11:32:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 11:32:41 -0000 Subject: [GHC] #10643: GHC cannot import submodules when run from subfolder In-Reply-To: <044.3c9adfa0c2ca70fe317024c4892ed64f@haskell.org> References: <044.3c9adfa0c2ca70fe317024c4892ed64f@haskell.org> Message-ID: <059.15a4e1303a66f286a6ea41acdd211483@haskell.org> #10643: GHC cannot import submodules when run from subfolder -------------------------------------+------------------------------------- Reporter: FPtje | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: subfolder | import submodule cd Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #3140 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #3140 Comment: Also reported as #3140, in a Windows setting (double clicking `Yes/A.hs` doesn't work). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:04:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:04:11 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.d4b7fb8d75a8632c833097693e297c22@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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 adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:06:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:06:51 -0000 Subject: [GHC] #11352: Allow applying type to label In-Reply-To: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> References: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> Message-ID: <066.2968741e7cff6438491b2894be725cda@haskell.org> #11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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 adamgundry): * owner: => adamgundry * keywords: => ORF * version: 7.10.3 => 7.11 * component: Compiler => Compiler (Type checker) * failure: None/Unknown => GHC rejects valid program Comment: I don't see any reason why this shouldn't work, I suspect the overloaded labels implementation just needs a bit of re-organization now that visible type application is implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:07:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:07:34 -0000 Subject: [GHC] #11103: DuplicateRecordFields + TemplateHaskell In-Reply-To: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> References: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> Message-ID: <064.a2e0a85961700c706f841d89bdbf1961@haskell.org> #11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1586 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:08:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:08:15 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.d864030cf2be1d1c21f433ff544e6ca9@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1585 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:08:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:08:37 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.d5f40a53833cc97fd24fedce6fda6f9c@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: adamgundry Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11167 | Differential Rev(s): Phab:D1600 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:12:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:12:43 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.d5a56369f94b829540dfd743c10b6c2c@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact 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 ekmett): It appears that #10444 does indeed bring GHC in line with the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 12:42:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 12:42:13 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.587c542e47f953e104b3517455701122@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it. Doubtless thinking of suitable names will be the most awkward bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 13:20:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 13:20:43 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.c3d9e01d62cfcdb5025889aeee38c10d@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'm likewise in favor, so long as these are new combinators and we don't go and kill all the existing combinators. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 13:33:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 13:33:53 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.3080573678fb2f720ae7e707321036ec@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1562 Comment: Perhaps we can close this now since we've merged Phab:D1562? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 14:31:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 14:31:58 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.bbedc501752daac34821059c37dbbc9b@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It's not quite done yet, I still have to finish TH (`recover` isn't implemented), and do something about the GHCi debugger. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 14:34:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 14:34:09 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.e73475e196eed799a365f2789809a3cb@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 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 simonmar): * owner: simonmar => * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 14:41:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 14:41:55 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.1bb4cdfc6d2d08d7968521ec74e13d0c@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The NCG tracks the current state of %rsp during code generation (see `getDeltaNat`) and emits hints into the generated code with the pseudo- instruction `DELTA`. It seems like we should be able to generate correct directives for the assembler from the `DELTA` instructions, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 14:43:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 14:43:30 -0000 Subject: [GHC] #10579: full module names of names not in scope have gone missing in ghci In-Reply-To: <047.b63d248973b529e66515b0b0ffe3a663@haskell.org> References: <047.b63d248973b529e66515b0b0ffe3a663@haskell.org> Message-ID: <062.871cb65ea822ea07f822daa61716a212@haskell.org> #10579: full module names of names not in scope have gone missing in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11208 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 14:56:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 14:56:07 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.94ceb713966eadabf0d7601369095d6c@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1737 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:04:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:04:24 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.caf3f8bb0f5846d949b1f187649ae0ef@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by simonpj): George: short term, can we just degrade gracefully for now, and do something that doesn't blow up, at the expense of maybe reporting fewer warnings? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:06:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:06:36 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.416237a0bb26f299cb8327ba552dcb38@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:08:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:08:44 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.d6168570c768bfb24acafa8eb352926a@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: > This ticket exists to coordinate work on Nick Frisby's '''late lambda- > lifting''' optimisation. > > * Wiki page: [wiki:LateLamLift]. All the details are here. > > * Branch in GHC repo: `wip/llf` > > * Related tickets > * #9279: local closure remains in final program > * #9374: static argument transformation New description: This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation * #5945 * #11284 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:09:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:09:22 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.877c618197ae10c05f286063db4c202b@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5945, #11318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #9476 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:13:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:13:39 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.8456e7f23087f0885c2100d8c34de461@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:14:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:14:26 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error In-Reply-To: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> References: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> Message-ID: <064.9fbd20db7d24b68a48420ba18f2613f7@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:15:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:15:09 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.5a8cc0bd205c21cf036e9506575383e3@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:15:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:15:23 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.c5e719ac2ccb7d57616ae859f7d25ac9@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:15:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:15:45 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.081b817f3a72f57fca333de71f18551c@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:19:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:19:36 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.26e81052af0e4fa919e7069a7b3a9776@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:24:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:24:36 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.b1992848c57813a3ad4969c1d81a38c1@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by gkaracha): Hmmm, the problem appears only with data families right now I think. Dropping the wrapper in the general case does not help because we end up with non-satisfiable constraints. We could deactivate pm checking for matches that contain `CoPat`s but this goes beyond data families (as the original test case without the signature has shown). I am still trying some ideas but I do not know exactly how much time will I need or if they are going to work after all. What is the time frame? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:26:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:26:50 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.7238193a75ff31e078655be61cf82a5b@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new * owner: simonpj => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:33:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:33:24 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.8094e1ea63ab39ff3c03b4908f468079@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * Do we have any (reproducible) evidence showing that this change makes things go faster? Perhaps a benchmark test of the relevant functions themselves? That would be helpful. Once we have that evidence, we can go ahead and commit. * Secondly, are the changes something that a reasonable person might expect the optimiser should be able to do by itself? If so, why doesn't it? Let's not close the ticket until we know about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:34:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:34:26 -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.13fa3506914cf5b024283f92cd7854be@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:43:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:43:10 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.6799cf1f5b8e836a943506d0dad8db68@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ben says that he got ''seg-faults'' when making `cpe_ExprIsTrivial` simply call `litIsTrivial`. That is deeply mysterious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 15:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 15:57:42 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.80828ae4d4524b78bd1b810ef685177f@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): To get the ball rolling I suggest prefixing them with {in?,}definite articles: {{{#!hs aNat :: forall n. KnownNat n => Natural theNat :: forall n. KnownNat n => Natural aSymbol :: forall s. KnownSymbol s => String theSymbol :: forall s. KnownSymbol s => String aTypeRep :: forall t. Typeable t => TypeRep theTypeRep :: forall t. Typeable t => TypeRep theSizeOf :: forall s. Storable s => Int theSizeOf = sizeOf @s undefined }}} For the '''''T'''angent '''o'''f '''t'''he '''D'''ay'' ('''''a'''s '''a''' '''S'''ervice'') (''TotD''(''aaS'')), how should the inclusion of Natural in base influence functions and other libraries? Functions like `length`, `take`, `drop`, `splitAt`, `replicate` scream for natural numbers as their arguments: Their types are of course well established, `Int` is also fixed- while `Natural` is arbitrary-precision. Is `Word` suitable? Maybe not worth it. Lens defines `instance FunctorWithIndex Int []` whose functional dependency forbids indexing lists by (arguably more ?natural?) `Natural` or `Word`. Changing them retroactively is a pain, but does it make sense in a perfect world? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:03:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:03:07 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.dd58f429ed476087278386dc235d85c3@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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 simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:16:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:16:44 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.e35918b299e8484f3755e6774a4402ff@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: bgamari (added) Old description: > This ticket exists to coordinate work on Nick Frisby's '''late lambda- > lifting''' optimisation. > > * Wiki page: [wiki:LateLamLift]. All the details are here. > > * Branch in GHC repo: `wip/llf` > > * Related tickets > * #9279: local closure remains in final program > * #9374: static argument transformation > * #5945 > * #11284 New description: This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:17:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:17:24 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.3cb2fdb0d7b5871e0eb2d4d3d33365cd@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 bgamari: Old description: > This ticket exists to coordinate work on Nick Frisby's '''late lambda- > lifting''' optimisation. > > * Wiki page: [wiki:LateLamLift]. All the details are here. > > * Branch in GHC repo: `wip/llf` > > * Related tickets > * #9279: local closure remains in final program > * #9374: static argument transformation New description: This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation * #5945 * #11284 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:22:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:22:17 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.122ffb91ab41aeaaff774c411ab01749@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5945, #11318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Closing as a duplicate given that this is a consequence of #9476. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:24:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:24:05 -0000 Subject: [GHC] #5945: Lambda lifting In-Reply-To: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> References: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> Message-ID: <061.3437fc474b57aba15dfb59d2f79a6719@haskell.org> #5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: There is an unmerged branch that implements late lambda-lifting. See [[LateLamLift]] and #9476. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:24:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:24:16 -0000 Subject: [GHC] #5945: Lambda lifting In-Reply-To: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> References: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> Message-ID: <061.d7e4c08cd8da9e84ba44784ccc7398fc@haskell.org> #5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284, #9476 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11284 => #11284, #9476 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:24:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:24:24 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.65c9ee5a471ed62be9c0d973373674a4@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: LateLamLift | -------------------------------------+------------------------------------- Changes (by bgamari): * wikipage: => LateLamLift -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 16:42:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 16:42:07 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.36b0c25c147fe75bd04758abb2326858@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:4 Iceland_jack]: > For the '''''T'''angent '''o'''f '''t'''he '''D'''ay'' ('''''a'''s '''a''' '''S'''ervice'') (''TotD''(''aaS'')), how should the inclusion of Natural in base influence functions and other libraries? Off-topic, but... > Functions like `length`, `take`, `drop`, `splitAt`, `replicate` scream for natural numbers as their arguments: Their types are of course well established, `Int` is also fixed- while `Natural` is arbitrary-precision. Is `Word` suitable? Maybe not worth it. Very unsuitable as long as subtraction on Word has wrap-around behavior rather than erroring. You would fail to catch a lot of programming errors that way, when passing wrapped values to functions that used to check whether their argument was negative, and in other cases you would silently change program behavior, when using functions that used to treat negative values as 0. See http://www.wabbo.org/blog/2014/22aug_on_bananas.html for a related example from Rust. Word is basically useless as an "efficient small-ish Natural" for this reason, and only makes sense when you specifically want the machine- specific wrap-around behavior, or when doing bit manipulation only. (And yes, Int can overflow too, making it somewhat less effective as an "efficient small-ish Integer", but overflowing an Int computation requires large inputs (which are often impossible to provide to the program in practice), while a Word computation can be overflowed with very small inputs.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:00:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:00:45 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.e9034ff456bb39076f190f5e3bd6d367@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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 mpickering): I definitely think that a special case should be added then. It is extremely unexpected to have to add a type signature for something like `(A 10) { a = 5 }`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:10:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:10:17 -0000 Subject: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? In-Reply-To: <042.7aea578c33e94085f5776f18cba04998@haskell.org> References: <042.7aea578c33e94085f5776f18cba04998@haskell.org> Message-ID: <057.946bfe3be8679bcaa4439c093507232c@haskell.org> #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:10:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:10:39 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.92c927956dda4fb8425756bc30aa8178@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics 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): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:11:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:11:23 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.a82ab502248bcceba321afe1e350b2da@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Generics 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:D1283 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:11:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:11:37 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.b432b42272835b91c15cf8a5edbbb49e@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:11:47 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.ef1bddce6eaf374decad28bc44a728f8@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1646 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:11:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:11:57 -0000 Subject: [GHC] #10604: Make Generic1 kind polymorphic In-Reply-To: <050.900476330e5007bcb132f742a5f2d072@haskell.org> References: <050.900476330e5007bcb132f742a5f2d072@haskell.org> Message-ID: <065.e56d6de8597ecbe61579bb2fb6ac571b@haskell.org> #10604: Make Generic1 kind polymorphic -------------------------------------+------------------------------------- Reporter: DerekElkins | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:12:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:12:10 -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.107f3cf1741a550db6886ed7002e8dbc@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:12:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:12:23 -0000 Subject: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules In-Reply-To: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> References: <051.f823b016355f38c348182e98da9d4ae1@haskell.org> Message-ID: <066.1b3db495d9ff4ccb37587fa3c9ed790d@haskell.org> #10487: DeriveGeneric breaks when the same data name is used in different modules -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1081 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:12:32 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.b8b62c702a657da5d518c5fbec048f1a@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8560 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:12:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:12:41 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.70865aecd523b70051a2b0a2e1b520a3@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: kosmikus Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9043 Related Tickets: #9043 | Differential Rev(s): Phab:D493 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:12:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:12:50 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.4de1fc109c95ad9e2b989414ee203bee@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T9968, | should_fail/T9968a Blocked By: | Blocking: Related Tickets: #9821 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:13:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:13:37 -0000 Subject: [GHC] #9821: DeriveAnyClass support for higher-kinded classes + some more comments In-Reply-To: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> References: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> Message-ID: <061.ae9442cb4c0b263804a661a24c45c5b3@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5462, #9968 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:17:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:17:15 -0000 Subject: [GHC] #7459: deriving Generic does not work with TypeLits In-Reply-To: <050.dea8df7cdfffe3e0bb4782a6ad14924e@haskell.org> References: <050.dea8df7cdfffe3e0bb4782a6ad14924e@haskell.org> Message-ID: <065.1900a384f2ef7c96f300fb388467baff@haskell.org> #7459: deriving Generic does not work with TypeLits -------------------------------------+------------------------------------- Reporter: maxtaldykin | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Generics 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 simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:18:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:18:26 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.087d1e31fcc2738ac95f9e071f515e49@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:18:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:18:42 -0000 Subject: [GHC] #8560: Derive some generic representation for GADTs In-Reply-To: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> References: <045.08c7497f3d39ab287608a0acc7513dc1@haskell.org> Message-ID: <060.0ed76dbd370fea66562e2852539dd34f@haskell.org> #8560: Derive some generic representation for GADTs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:19:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:19:02 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.11a1c1ea61c3a71bf7472111283811fd@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:19:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:19:18 -0000 Subject: [GHC] #9453: The example for GHC Generics is kinda broken In-Reply-To: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> References: <048.c02d7125de3f7412f313a5047debffc6@haskell.org> Message-ID: <063.00504afc7fe85a1bc3152485073cd599@haskell.org> #9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Generics 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 simonpj): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:19:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:19:35 -0000 Subject: [GHC] #9526: Add missing Generic instances in base In-Reply-To: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> References: <042.36fe33d326f024375b013e70748f1e6c@haskell.org> Message-ID: <057.1147a4c47f6727d8f7497b5922109737@haskell.org> #9526: Add missing Generic instances in base -------------------------------------+------------------------------------- Reporter: nh2 | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:20:11 -0000 Subject: [GHC] #10512: Generic instances missing for Int32, Word64 etc. In-Reply-To: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> References: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> Message-ID: <066.f4d496a230d1db1fda350cfb61c10d20@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Generics 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: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:24:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:24:45 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.fc8cc7dbf2cf29ef33d3b61b07ad084d@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: LateLamLift | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > This ticket exists to coordinate work on Nick Frisby's '''late lambda- > lifting''' optimisation. > > * Wiki page: [wiki:LateLamLift]. All the details are here. > > * Branch in GHC repo: `wip/llf` > > * Related tickets > * #9279: local closure remains in final program > * #9374: static argument transformation > * #5945 > * #11284 New description: This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation * #5945 (closed as dup, but with useful example) * #11284 (closed as dup, but with useful example) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:31:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:31:31 -0000 Subject: [GHC] #11344: Rule "and/build" not firing In-Reply-To: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> References: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> Message-ID: <064.6b6290770be04b00b75d38da5bdc5270@haskell.org> #11344: Rule "and/build" not firing -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9848 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can someone check if the fix to #9848 fixes this ticket too? ANd add a regression test? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:42:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:42:10 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.033ea108fdc1321519eb3ee50dd6a83f@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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): The trouble is that it's hard to say precisely when inference should succeed. How would you suggest writing the specification of what is and is not accepted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 18:01:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 18:01:02 -0000 Subject: [GHC] #2140: cpuTimePrecision is wrong (was: cpuTimePrecision is wrong for me on Windows (XP)) In-Reply-To: <044.c00dea462eff931d52d78fdca8894af2@haskell.org> References: <044.c00dea462eff931d52d78fdca8894af2@haskell.org> Message-ID: <059.52af47301c2ecccba317e5514cbc29b7@haskell.org> #2140: cpuTimePrecision is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.8.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 thomie): * cc: ekmett (added) * failure: => None/Unknown * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: 8.0.1 => * os: Windows => Unknown/Multiple Comment: The module `CPUTime` is part of the [https://www.haskell.org/onlinereport/cputime.html Haskell 98 report] (but not the Haskell 2010 report). Computation `getCPUTime` returns the number of picoseconds of CPU time used by the current program. The precision of this result is given by `cpuTimePrecision`. This is the smallest measurable difference in CPU time that the implementation can record, and is given as an integral number of picoseconds. == getCPUTime == > getCPUTime always returns a multiple of 15625000000 http://stackoverflow.com/a/29164665 explains this as follows: the clock is updated 64 times per second, at the clock tick interrupt. Or in other words 1 / 64 = 0.015625 between ticks And `0.015625 seconds = 15625000000 picoseconds`. == cpuTimePrecision == The current implementation of `cpuTimePrecision` looks at the value of `clockTicks = clk_tck()` (see #7519), converted to picoseconds. On my Linux system, `clk_tck` calls `sysconf(_SC_CLK_TCK)` and always returns `100` (see `libraries/base/cbits/sysconf.c`, and note that `CLK_TCK` is only defined when `#undef __USE_XOPEN2K`, see `/usr/include/time.h` and `/usr/include/x86_64-linux-gnu/bits/time.h`). On Windows, `clk_tck` seems to always return `CLK_TCK = 1000` (see `./opt/ghc-7.10.3/mingw/x86_64-w64-mingw32/include/time.h`). These values don't seem related in any way to the precision of `getCPUTime`. From `man sysconf`: clock ticks - _SC_CLK_TCK The number of clock ticks per second. The corresponding vari? able is obsolete. It was of course called CLK_TCK. (Note: the macro CLOCKS_PER_SEC does not give information: it must equal 1000000.) According to this [http://stackoverflow.com/questions/19919881/sysconf-sc- clk-tck-what-does-it-return?rq=1#comment29641173_19919970 stackoverflow comment]: it's the number of times the timer interrupts the CPU for scheduling and other tasks, 100Hz is a common value, higher frequency equals higher timer resolution and more overhead. == Solution ? == > Does anyone happen to know where we can get real values for this for any platforms? I don't know, but on Windows, you can supposedly use [https://msdn.microsoft.com/en- us/library/windows/desktop/ms724394%28v=vs.85%29.aspx GetSystemTimeAdjustment]. Some more discussion here: http://lists.ntp.org/pipermail/questions/2011-September/030583.html. But maybe we should just give up, since `CPUTime` is not part of the Haskell report anymore. Keep the function `cpuTimePrecision` for backward compatibility, but change the docstring to say what it really does: return the number of picoseconds between clock ticks. This issue was also discussed in this thread: https://mail.haskell.org/pipermail/libraries/2008-February/009305.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 18:21:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 18:21:35 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.270971731c6c48f4459b3fa8cd89e068@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10828 | Differential Rev(s): Phab:D1738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D1738 * related: => #10828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 18:40:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 18:40:52 -0000 Subject: [GHC] #2140: cpuTimePrecision is wrong In-Reply-To: <044.c00dea462eff931d52d78fdca8894af2@haskell.org> References: <044.c00dea462eff931d52d78fdca8894af2@haskell.org> Message-ID: <059.369e2d371e677957ca444f17b234fa4a@haskell.org> #2140: cpuTimePrecision is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.8.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: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Documentation bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 19:11:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 19:11:22 -0000 Subject: [GHC] #11352: Allow applying type to label In-Reply-To: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> References: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> Message-ID: <066.b6f0892ebfee24cddd9715463c66148a@haskell.org> #11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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 adamgundry): * owner: adamgundry => Comment: Hmm, this isn't as straightforward as I thought. We could change the type of `fromLabel` to be `forall x a . IsLabel x a => a`, and then implement `#answer` by replacing it with `fromLabel @"answer"`. That gives you the behaviour you want, but it means that error messages mention applications of `fromLabel`, e.g. {{{ Could not deduce (IsLabel "y" t) arising from the overloaded label ?#y? }}} becomes {{{ Could not deduce (IsLabel "y" t) arising from a use of ?fromLabel? }}} which is somewhat undesirable. Moreover, overloaded string/numeric literals are similarly incompatible with visible type application. So I'm inclined to leave things as they are: after all, you can always write `#answer :: Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 19:18:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 19:18:28 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.0de03567519447398edec71a079abf30@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): > Why should the instance declarations affect the kind of the type constructor? We could always find type families mentioned in GADT data constructors, but with GADT data constructor promotion, we can therefore find these families mentioned in kinds: {{{#!hs type family TrivialFamily (t :: Type) :: Type type instance TrivialFamily t = Bool data Q where Q :: TrivialFamily Int -> Q -- The type of the data constructor Q :: Bool -> Q -- The kind of the promoted data constructor. -- GHC actually gives 'Q :: TrivialFamily Int -> Q -- but it *should* flatten that to Bool. 'Q :: Bool -> Q -- This will not kind-check, unless we import the -- TrivialFamily t instance. type Problem = 'Q 'True }}} To check that a use of `'Q` is well-kinded, we must know `TrivialFamily Int`. Pardon my earlier comment, this bug can arise ''without'' switching on `TypeInType`. > If you're up to this task, that would be wonderful. Absolutely. This bug is blocking a project of mine so I want it fixed asap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 19:23:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 19:23:12 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.28ed17c73b74f40d3e29e2c5baf7ffc9@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): It looks like things are a bit more complicated than we thought. Judging by https://github.com/ghc/ghc/blob/master/compiler/iface/MkIface.hs#L219 and https://github.com/ghc/ghc/blob/master/compiler/iface/MkIface.hs#L425 ghc already filters out wired-in names during fingerprinting. In fact, the real problem is that the `GHC.Stack.Types.CallStack` Name that triggers the exception '''isn't''' wired-in, which is completely bogus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 19:25:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 19:25:42 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.4488a640b32f02cac7fd3214536c3b2b@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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): At the moment we permit `(aThing :: A) { a = 5 }` because there is a special rule that looks for a type signature on the record expression. We could have a similar rule that looks for a variable of known type, which would permit `aThing { a = 5 }`. We'd yet need another rule for `(A 10) { a = 5 }`; that one looks less useful to me. None of this is doing true inference, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 19:35:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 19:35:46 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" Message-ID: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 was slightly surprised to discover that the combination of `TypeApplications` and `RankNTypes` allows impredicative instantiations, for example: {{{#!hs map @(forall a . a) :: ((forall a. a) -> b) -> [forall a. a] -> [b] }}} Is this desirable, or should it require `ImpredicativeTypes`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 19:55:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 19:55:18 -0000 Subject: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? In-Reply-To: <042.a892bb62d9bf138a3680ca1e496e0413@haskell.org> References: <042.a892bb62d9bf138a3680ca1e496e0413@haskell.org> Message-ID: <057.4e78e8eb46d7ee34731ff6c6cbb97910@haskell.org> #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? -------------------------------------+------------------------------------- Reporter: jvl | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Driver | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): It seems the first issue is fixed. Without `-no-hs-main` we get a link error, as expected: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ ghc -c -o MyHelloWorld.o MyHelloWorld.hs $ ghc -o hello.exe mymain.c MyHelloWorld.o -fforce-recomp C:\msys64\tmp\ghc5784_0\ghc_4.o:ghc_3.c:(.text+0x0): multiple definition of `main' }}} With `-no-hs-main` it works: {{{ $ ghc -c -o MyHelloWorld.o MyHelloWorld.hs $ ghc -no-hs-main -o hello.exe mymain.c MyHelloWorld.o -fforce-recomp $ ./hello.exe Hello World }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:03:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:03:42 -0000 Subject: [GHC] #11356: GHC panic Message-ID: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached file causes GHC (version 8.1.20160102) panic. I tried shrinking, attached code is bogus at this point. Interestingly inlining the type synonym `T = Nat` into Category's superclass context fixes the panic, and causes a regular error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:04:05 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.2f1506ed9e2f04484ac8fda8e3a9de83@haskell.org> #11356: GHC panic --------------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+--------------------------- Changes (by Iceland_jack): * Attachment "Foo.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:04:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:04:50 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.f7fd28cf5096bb0bbd664e03a753e589@haskell.org> #11356: GHC panic --------------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+--------------------------- Changes (by Iceland_jack): * Attachment "Foo.log" added. ghci -ignore-dot-ghci -v /tmp/Foo.hs &> /tmp/Foo.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:07:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:07:27 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.e1384c2edcc7d355b1c43f16076945ec@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:07:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:07:56 -0000 Subject: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? In-Reply-To: <042.a892bb62d9bf138a3680ca1e496e0413@haskell.org> References: <042.a892bb62d9bf138a3680ca1e496e0413@haskell.org> Message-ID: <057.a7cd1617ba17579efd7987385e9a0675@haskell.org> #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? -------------------------------------+------------------------------------- Reporter: jvl | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Driver | Version: 6.8.2 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme * milestone: 8.0.1 => Comment: > the last example [from comment:1] should work. And it does (without `-fglasgow-exts` an `MyHelloWorld_stub.o`): {{{ $ ghc -c -o MyHelloWorld.o MyHelloWorld.hs $ ghc -optl-mwindows -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o $ echo $? 0 }}} I'm going to assume this issue has been fixed a long time ago (ticket opened 7 year ago). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:28:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:28:10 -0000 Subject: [GHC] #4800: Memory Leak when Compiling qtHaskell In-Reply-To: <044.ee1af1cd10ac65da1eed8d844eae3073@haskell.org> References: <044.ee1af1cd10ac65da1eed8d844eae3073@haskell.org> Message-ID: <059.00cb314b276720b76730c1266f199e8f@haskell.org> #4800: Memory Leak when Compiling qtHaskell -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | developer.berlios.de/project/showfiles.php?group_id=10072 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: Replying to [comment:3 mtreskin]: > Have the same problem on Linux amd64 with 64-bit GHC. Given that this issue was opened 5 years ago, no new reports have been made since, and [http://qthaskell.berlios.de/ qtHaskell] itself seems dead (There is https://github.com/keera-studios/hsQt, which does seem active), I'm going to close this issue. Resolution "invalid", because there is no way to reproduce (anymore). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 20:29:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 20:29:41 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.1aa470b8b1250e5bfb40d1035226291a@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Comment (by MarcelineVQ): For me the feature is more important than the name so I don't mind changing to anything at all if people need it changed, I'll wait and see. Currently I'm looking into a rewrite for rts flag parsing so here's some additional considerations: * maxN may not end up having a weird overlap if parsing works differently * it could make sense to not have maxN added yet in case it's likely to change again in the semi-near future * conversely if there ends up being some flag changes anyway then a newer one changing isn't as big a deal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 21:07:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 21:07:10 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.0bae3db2a15daa8d1e5c3ce149a3b0da@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1737 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"77494fa9fa34c1a831caabc194e855167de0c2d9/ghc" 77494fa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="77494fa9fa34c1a831caabc194e855167de0c2d9" Remove -Wtoo-many-guards from default flags (fixes #11316) Since #11316 indicates that having flag `-Wtoo-many-guards` enabled by default causes issues, the simplest thing is to remove it. This patch removes it from the default list, it updates the docs and removes the suppression flags for `T783` and `types/OptCoercion.hs` Test Plan: validate Reviewers: bgamari, austin, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1737 GHC Trac Issues: #11316 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 21:07:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 21:07:10 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.d9c94c6dfe7352fc8daf0a805844ff3d@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"cdeefa44ac8e2452a691708715bd2157a7bf3f0e/ghc" cdeefa4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cdeefa44ac8e2452a691708715bd2157a7bf3f0e" ghc.mk: Add reference to Trac #5987 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 21:49:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 21:49:22 -0000 Subject: [GHC] #11268: Extend ghc environment file features In-Reply-To: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> References: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> Message-ID: <057.2fa2f026b2724fe1a69129a131e19132@haskell.org> #11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: duncan Type: feature request | Status: patch Priority: highest | Milestone: 8.0.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:D1668 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa699b94e3a8ec92bcfa8ba3dbd6b0de15de8873/ghc" aa699b94/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa699b94e3a8ec92bcfa8ba3dbd6b0de15de8873" Extend ghc environment file features A set of changes to enable local ghc env files to be useful for tools like cabal. Ultimately it will allow cabal to maintain a ghc env file so that users can simple run ghc or ghci in a project directory and get the expected environment of the project. Change the name of .ghc.environment files to include the platform and ghc version, e.g. .ghc.environment.x86_64-linux-7.6.3, since their content is version specific. Strictly speaking this is not backwards compatible, but we think this feature is not widely used yet. "Look up" for a local env file, like the behaviour of git/darcs etc. So you can be anywhere within a project and get the expected environment. Don't look for local env files when -hide-all-packages is given. Extend the syntax of env files to allow specifying package dbs too. Test Plan: Currently completely untested. Compiles, that is all. Sorry, have to disappear for the hols. Reviewers: hvr, ezyang, austin, bgamari Reviewed By: ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1668 GHC Trac Issues: #11268 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 22:41:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 22:41:59 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.ff0230a256f1ce92b56d4a7ca69dbbac@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1739 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 23:33:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 23:33:13 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.69b3fbc1daf238f3c1fc1ab4dad240a7@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | 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 Tue Jan 5 23:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 23:51:08 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.8cc7183287a65e9adf21333ec6499d73@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes, that patch looks right. Does it cure the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 23:52:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 23:52:18 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family Message-ID: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: Generics, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC 7.10.3, the following code compiles: {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module ProxyFam where import GHC.Generics (Generic1) data family ProxyFam (a :: k) data instance ProxyFam (a :: k) = ProxyCon deriving Generic1 }}} But on GHC 8.1, it fails: {{{ $ /opt/ghc/head/bin/ghc ProxyFam.hs [1 of 1] Compiling ProxyFam ( ProxyFam.hs, ProxyFam.o ) ProxyFam.hs:10:53: error: ? Can't make a derived instance of ?Generic1 ProxyFam?: ProxyFam must not be instantiated; try deriving `ProxyFam k a' instead ? In the data instance declaration for ?ProxyFam? }}} I'm not sure what exactly is going on here, but I have a hunch. The `Generic1` typeclass is of kind `* -> *`, which means that in a `Generic1 ProxyFam` instance, the kind of `a` is instantiated to `*`. Curiously, though, the same error does ''not'' appear when `deriving Generic` for a normal datatype (e.g., `data ProxyFam (a :: k) = ProxyCon deriving Generic1`). Richard, I'm stuck as to how to fix this. I suspect this was triggered by `-XTypeInType`-related changes, specifically, [http://git.haskell.org/ghc.git/blobdiff/6e56ac58a6905197412d58e32792a04a63b94d7e..6746549772c5cc0ac66c0fce562f297f4d4b80a2:/compiler/typecheck/TcGenGenerics.hs this change]: {{{#!diff diff --git a/compiler/typecheck/TcGenGenerics.hs b/compiler/typecheck/TcGenGenerics.hs index 2c5b80e..fb18517 100644 (file) --- a/compiler/typecheck/TcGenGenerics.hs +++ b/compiler/typecheck/TcGenGenerics.hs @@ -147,7 +146,7 @@ canDoGenerics tc tc_args -- -- Data family indices can be instantiated; the `tc_args` here are -- the representation tycon args - (if (all isTyVarTy (filterOut isKind tc_args)) + (if (all isTyVarTy (filterOutInvisibleTypes tc tc_args)) then IsValid else NotValid (tc_name <+> text "must not be instantiated;" <+> text "try deriving `" <> tc_name <+> tc_tys <> }}} What exactly does `filterOutInvisibleTypes` do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 23:58:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 23:58:17 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.15906e2e1a7536d2874e2d897690ba33@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 23:59:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 23:59:22 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.9b07d6a77d78746cb586b59d24295e69@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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's far from clear what a "known type" is in "a variable of known type". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 00:34:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 00:34:50 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.7263f9ce82f7e4dee31cd38376338228@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Yep, `make slowtest TEST=tc198` passes locally now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 00:41:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 00:41:31 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.e2e5f944c3b1b69ff543b9ce9562d94d@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): Replying to [comment:46 bgamari]: > > My understanding of this situation is that it is not an intrinsic limitation of PE. The relevant data structures are the `.edata` and `.idata` tables which are defined in sections 63 and 64 of the PE/COFF specification. The specification specifies that one means of referring to exported symbols is via a 16-bit ordinal. However, this is not the only way; if the lookup fails the loader will fall back to a standard name search. Indeed, Microsoft even explicitly says that ordinals [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy artifact]] and their use is discouraged in new code (this document describes the `.def` format, but the idea still applies), > Your understanding doesn't match my understanding of the PE/COFF specification. Page 75 of the 02/06/2013 version of the spec which is the page where the Export Ordinal Table of the `.edata` section is described. The section includes pseudo-code explaining how the SymbolRVA of a named symbol is determined: i = Search_ExportNameTable(ExportName); ordinal = ExportOrdinalTable[i]; SymbolRVA = ExportAddressTable[ordinal - ordinalBase]; So, the problem isn't with this pseudo-code, but the pseudo-code combined with the Export Ordinal Table being defined as: > > `The export ordinal table is an array of 16-bit indexes into the address table.` This is especially sad, since the Address Table Entries field of the Export Directory Table is 32 bits of data. The text you quote below is from the syntax of .DEF files explaining why 16-bit DLLs, didn't include exported symbol string names and utilized the ordinal number as the ONLY `API` between DLLs. The documentation you quote is recommending usage of string symbols for providing a cross-DLL `API` resolution and only using the ordinal `API` for legacy reasons. The documentation doesn't mean to imply that ordinals are optional (based on my reading of the PE/COFF sections about .edata). > > You can use @ordinal to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don?t recommend exporting functions by ordinal unless your DLL?s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL. > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 01:44:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 01:44:47 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.8a927ffab915f9a2a24afec012b6408a@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): I did take another look at the {{{lookup}}} function and compared the core and the generated cmm in both cases. There was nothing special to see in the core as both versions compile to simple loops without any unexpected things like a dictionary floating around. The IO version only packs the result into an unboxed tuple with the state token while the pure version lacks this (of course). The cmm of both versions sheds more light on the reason for the speedup: GHC compiles the pure version to a nice loop which does not jump back to the beginning of the function, but behind the stack check (the stack is needed to evaluate unevaluated buckets), while the IO version just calls itself recursively (i.e. jumps before the stack check). Otherwise they seemed pretty identical as far as I could tell. And sadly my measurement of the speedup was wrong as I only took the original benchmark from cdk and modified it as necessary. The original version consumes all my memory as criterion runs benchmarks multiple times and mutable data structures are somewhat sensitive to such a behavior, especially if the insert operation extends already existing elements. So the first thing I did was replacing the lists with sets, which are less sensitive if an existing element is inserted a second time. Another important thing was the order in which benchmarks are run: If we first insert in all competing implementations, the second implementation suffers from a heap with more live data, meaning longer GC delays. So I changed the order in such a way that first one implementation is run, then another one while the first one is already no longer reachable and thus will be GCed. A third thing I noticed (but only after looking at the core) was that my change actually increases the laziness of {{{lookup}}}. The original implementation would determine whether the result is a {{{Just}}} or {{{Nothing}}} while my implementation returns a thunk. I though I was safe by using {{{nfIO}}} in the benchmark to evaluate my result, but actually I did not read that code carefully and first missed the actual place the result is evaluated - or not. Fixing this yields a more reasonable speedup of something around 10-15% (which also fits the observed differences in the cmm much better). I can (try to) attach the modified benchmark, if this helps. I did also take another look at the unused argument in {{{updateWith.go}}} and am now quite sure that it is something leftover from the development of the function which has no actual function anymore and can safely be removed. I guess it would have never been in the original commit, but it seems hard or impossible to correctly identity such unused arguments (I mean, it is used, but only in a function which does not use it...). Especially, if such an argument would be used to pass a type to a recursive function, which just passes it on and uses ScopedTypeVariables to access the type, so it never touches the argument directly... And yes, I can hopefully try to submit the changes to Phabricator tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 03:29:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 03:29:41 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.5a0eb1591db85d8d4efff495cc39ba36@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType => Comment: On further thought, (5) from comment:2 is a bug, too. In any case, this one isn't my fault. I'm responsible for point (1) in comment:2, but that's an improvement (the file submitted ought not to be accepted, because it runs afoul of the monomorphism restriction). On the other hand, points (2) and (5), the real bugs, are around in 7.10. With 7.10.2, {{{ module Mono where foo :: Show a => a -> String (foo) = show }}} fails unless you enable `-XNoMonomorphismRestriction`. And {{{ module Mono where foo :: _ (foo) = id }}} succeeds, with no warnings. I conjecture that both problems are related to the fact that `decideGeneralisationPlan` always infers for pattern bindings. But I haven't looked into it more than that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 03:55:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 03:55:13 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.42baed567a71b2c65ea4b0dd6126b0b4@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): * owner: => RyanGlScott Comment: Actually, I realized that I was a little too careless in writing solutions 2 and 3?to the point where I skipped over an important detail: `InfixC` and `reifyFixity` serve distinct purposes. `InfixC` just tells you that a constructor was ''declared'' infix rather than prefix, i.e., it's the difference between {{{#!hs data T1 a = T1 a a }}} and {{{#!hs data T2 a = a `T2` a }}} But it tells you nothing about its actual fixity ''when used as an infix operator''. In fact, calling `reifyFixity` on both `'T1` and `'T2` would yield the same answer (`Fixity 9 InfixL`) since neither have an explicit fixity declaration. This is a minor distinction, but an important one. As a motivating example, when a datatype has a derived `Show` instance: * If one of its constructors is declared prefix, then the constructor will be shown before its fields, and the fields will always be shown with precedence 11. This is regardless of whether a fixity declaration is present. * If one of its constructors is declared infix, then the constructor will be shown between its two arguments, and the fields will shown according to the precedence in the fixity declaration plus 1 (if none is present, it defaults to 9+1). This is extremely important for GADTs because it is a special case. A GADT constructor is only considered to be declared infix if (a) it is an operator symbol, (b) it has two arguments, (c) it has a fixity declaration. Only then would a derived `Show` instance for a GADT constructor show the constructor between its arguments. For these reasons, proposals 2 and 3 above aren't quite accurate: * `InfixC` can't be subsumed under `NormalC` neatly because they discern a property of the datatype declaration that can't necessarily be gleaned from `reifyFixity`. Unless you were to add another field to `NormalC` to mark whether it was declared infix, that it?but that is another breaking change. * `InfixC` can't be subsumed under `RecC` at all, since if a constructor has records, it is automatically considered not to be declared infix. Considering all this, proposal 1 looks by far the most attractive in terms of ease of implementation and the least API changes (barring `GadtC`/`RecGadtC`). I think I'll go ahead and add an `InfixGadtC` constructor to `Con`. Any objections? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 03:56:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 03:56:34 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.f02b629cf0622a41502fb1388e444bd8@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | 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 goldfire): * owner: => goldfire * keywords: TypeInType => TypeApplications Comment: This is not desirable. I think I see why this happens, and I have a fix, but I actually can't reproduce. Do you have a minimal complete test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 04:44:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 04:44:01 -0000 Subject: [GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 Message-ID: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: Generics | 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: -------------------------------------+------------------------------------- Compile the following program with GHC 7.10.3 and 8.1: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} module Main (main) where import GHC.Generics infixr 1 `T` data T a = T a a deriving Generic instance HasFixity (T a) data I a = a `I` a deriving Generic instance HasFixity (I a) class HasFixity a where fixity :: a -> Fixity default fixity :: (Generic a, GHasFixity (Rep a)) => a -> Fixity fixity = gfixity . from class GHasFixity f where gfixity :: f a -> Fixity instance GHasFixity f => GHasFixity (D1 d f) where gfixity (M1 x) = gfixity x instance Constructor c => GHasFixity (C1 c f) where gfixity c = conFixity c main :: IO () main = do putStrLn $ show (fixity (T "a" "b")) ++ ", " ++ show (fixity ("a" `I` "b")) }}} On GHC 7.10.3, it yields `Prefix, Infix LeftAssociative 9`, but on GHC 8.1, it yields `Infix RightAssociative 1, Prefix`. Why? The implementation of `deriving Generic(1)` changed slightly in GHC 8.1. Before, it would only assign a fixity of `Infix` if a constructor was ''declared'' infix. But GHC 8.1 no longer checks for this?it first checks if there is a user- supplied fixity declaration, and if so, uses that as the `Fixity`. Otherwise, it defaults to `Prefix`, even if the datatype was declared infix! The design of `Fixity` perhaps leaves something to be desired, but at the very least, we should ensure nothing `Fixity`-related breaks for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 04:52:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 04:52:17 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.40176f213134855f2926642e537d8657@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): * Attachment "0002-Fix-11348-handle-instance-dependencies.patch" added. Fix candidate 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 05:18:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 05:18:25 -0000 Subject: [GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 In-Reply-To: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> References: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> Message-ID: <065.a2c9cf54abaed1364ea1ee69c08c5d9a@haskell.org> #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Generics 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:D1740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 05:32:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 05:32:52 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.40176f213134855f2926642e537d8657@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): * Attachment "0002-Fix-11348-handle-instance-dependencies.patch" removed. Fix candidate 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 05:32:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 05:32:52 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.2f0e7fa2506b61fcd13554358569e74a@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): * Attachment "0002-Fix-11348-handle-instance-dependencies.patch" added. Fix candidate 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 06:06:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 06:06:00 -0000 Subject: [GHC] #11092: ApiAnnotations : make annotation for shebang In-Reply-To: <044.0bd4290eed8d430160dff757f59d13b8@haskell.org> References: <044.0bd4290eed8d430160dff757f59d13b8@haskell.org> Message-ID: <059.1962f680b58abc951810648b22618298@haskell.org> #11092: ApiAnnotations : make annotation for shebang -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations 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 alanz): * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 06:06:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 06:06:54 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators In-Reply-To: <044.2722f1013c64633fbf159145867daa0f@haskell.org> References: <044.2722f1013c64633fbf159145867daa0f@haskell.org> Message-ID: <059.e45dbb6d882bb36cbdaf6d6d0a53162b@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 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 alanz): * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 07:57:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 07:57:47 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.63b93426741dae044ab9852be7e1db82@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 jstolarek): I think it would be better to add a field to `GadtC` that tells whether a constructor is an infix one or not. Correct me if I'm wrong, but information about infixity of a declaration is rarely needed. Adding a new constructor will force TH clients to implement handling of infix constructors even in situations where they don't care about infixity, whereas adding a new field to `GadtC` will be simple to handle - programmers can simply ignore that field in situations where it is irrelevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 08:52:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 08:52:14 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.9b36328a577054ac3ababf369790b08c@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you for taking the time to get more insight. Insight is what we need to take sensible action! > The cmm of both versions sheds more light on the reason for the speedup: GHC compiles the pure version to a nice loop which does not jump back to the beginning of the function, but behind the stack check (the stack is needed to evaluate unevaluated buckets), while the IO version just calls itself recursively (i.e. jumps before the stack check). Interesting, though I don't yet understand the details. Could you boil out a standalone example that demonstrates just this single issue? I.e. two versions of a function, one of which repeats the stack check and one of which doesn't, and show the code side by side? > but it seems hard or impossible to correctly identity such unused arguments (I mean, it is used, but only in a function which does not use it...). Well GHC's strictness analyser should find exactly this case. I'm puzzled why it does not. Again, could you spare a moment to make a standalone reproducer for just this issue? Or at least a smallish function I can compile in isolation to see this argument not disappearing. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 09:23:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 09:23:40 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.5cc762029141f01009b4a1798575a77a@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): You are so productive! But before generating a big patch, let's agree the design and approach. Thanks for comment:4; I think I get it now. Here's another way to say it; see if you agree. * When kind-checking a type declaration, we must obviously first check the declarations of any types it mentions. E.g. {{{ type S = Int type T = S -> S }}} We must kind-check `S` before `T` because `T` mentions `S`. * But we may also need to check a `type instance` declaration: {{{ type family F (a :: k) :: Type type instance F Int = Bool data K a = MK (F Int) type R = MK 'True }}} In the declaration of `R`, the (promoted) data constructor `MK` is given an argument of kind `Bool`, but it expects one of kind `F Int`. Things only work if we have processed the `type instance` declaration first. * Alas, there is no ''explicit'' dependency of the declaration of `R` on the `type instance` declaration. Indeed we might also have {{{ type instance F R = ...blah... }}} and we can't check ''that'' instance until after dealing with `R`. * Bottom line: we have to interleave processing of type/class decls with processing of `type instance` decls. So I think the algorithm must be this: '''always process a `type instance` declaration as soon as all the type constructors it mentions have been kind-checked'''. Algorithmically, we can't just add the `type instance` declarations to the strongly-connected component analysis for type/class decls, because of the lack of explicit dependencies. I think we have to * Do SCC on the type and class declarations as now * Keep in hand the set of un-processed `type instance` declarations * Before doing a type/class SCC, first process all the `type instance` decls whose free vars are imported, or are now bound in the type environment. * That results in a depleted set of un-processed `type instance` declarations. Does that sound right? Is it what your patch does? Incidentally this couldn't happen before `TypeInType` because previously we didn't promote data types like `K`. {{{ Foo.hs:9:10: Data constructor ?MK? comes from an un-promotable type ?K? In the type ?MK True? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 09:42:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 09:42:01 -0000 Subject: [GHC] #5376: Quotation in System.Process.system for Windows In-Reply-To: <046.28ab560abfd5d4e05c3ec95f2d90666b@haskell.org> References: <046.28ab560abfd5d4e05c3ec95f2d90666b@haskell.org> Message-ID: <061.7952b3d20c11334d19afe2e12125b423@haskell.org> #5376: Quotation in System.Process.system for Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: snoyberg Type: bug | Status: closed Priority: low | Milestone: Component: Core Libraries | Version: 7.0.4 Resolution: duplicate | 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 thomie): * cc: ekmett (added) * status: new => closed * resolution: => duplicate * milestone: 8.0.1 => Comment: Moved to https://github.com/haskell/process/issues/51. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 09:53:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 09:53:21 -0000 Subject: [GHC] #5251: copyFile does not copy metadata In-Reply-To: <044.decb8c1daad396e938c16a7753418497@haskell.org> References: <044.decb8c1daad396e938c16a7753418497@haskell.org> Message-ID: <059.e687946a58c694e321f213faf0a11fdc@haskell.org> #5251: copyFile does not copy metadata -------------------------------------+------------------------------------- Reporter: Orphi | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Core Libraries | Version: 7.0.2 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 thomie): * cc: ekmett (added) * status: new => closed * resolution: => duplicate * milestone: 8.0.1 => Comment: Moved to https://github.com/haskell/directory/issues/40. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 10:15:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 10:15:58 -0000 Subject: [GHC] #2140: cpuTimePrecision is wrong In-Reply-To: <044.c00dea462eff931d52d78fdca8894af2@haskell.org> References: <044.c00dea462eff931d52d78fdca8894af2@haskell.org> Message-ID: <059.51bee45170273bfc51386198f80b316c@haskell.org> #2140: cpuTimePrecision is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.8.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 bgamari): > But maybe we should just give up, since CPUTime is not part of the Haskell report anymore. Keep the function cpuTimePrecision for backward compatibility, but change the docstring to say what it really does: return the number of picoseconds between clock ticks. This sounds reasonable to me. For the record, I believe the relevant Linux interface here is `clock_getres` (which itself only has nanosecond resolution at best). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 10:16:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 10:16:12 -0000 Subject: [GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 In-Reply-To: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> References: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> Message-ID: <065.b0d55edfd8e880982398a8598f03a0c6@haskell.org> #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Generics 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:D1740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 10:57:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 10:57:04 -0000 Subject: [GHC] #11344: Rule "and/build" not firing In-Reply-To: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> References: <049.fd58e5d46bc9bd27749bf63af7a82a60@haskell.org> Message-ID: <064.b2cd073147135b276e42510d9377dbd1@haskell.org> #11344: Rule "and/build" not firing -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9848 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I did check, it fixes this (that?s why I closed it). Also, that ticket has a regression test for `and`. I think we are fine (besides slightly shamed that it is broken in 7.10). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 11:05:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 11:05:17 -0000 Subject: [GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 In-Reply-To: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> References: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> Message-ID: <065.6b0a6f7ca64b2d76496974cd96102b60@haskell.org> #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Generics 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:D1740 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"852b603029a047609a54453b1f9cd65035a43afe/ghc" 852b6030/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="852b603029a047609a54453b1f9cd65035a43afe" Restore old GHC generics behavior vis-?-vis Fixity Phab:D493 accidentally changed the way GHC generics looks up `Fixity` information when deriving `Generic` or `Generic1`. Before, a `Fixity` of `Infix` would be given only if a data constructor was declared infix, but now, `Infix` is given to any data constructor that has a fixity declaration (not to be confused with being declared infix!). This commit reverts back to the original behavior for consistency's sake. Fixes #11358. Test Plan: ./validate Reviewers: kosmikus, dreixel, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1740 GHC Trac Issues: #11358 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 11:31:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 11:31:04 -0000 Subject: [GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 In-Reply-To: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> References: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> Message-ID: <065.6f2334f70640c1990de10096107f37b5@haskell.org> #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Generics 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:D1740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 12:49:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 12:49:03 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.dcf4ec6e688d562dcef6e04baa4f49d3@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10828 | Differential Rev(s): Phab:D1738 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"cac0795af33d622e4c6ebae6ae1f206969287088/ghc" cac0795/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cac0795af33d622e4c6ebae6ae1f206969287088" Change Template Haskell representation of GADTs. Previous representation of GADTs in TH was not expressive enough to express possible GADT return types. See #11341 Test Plan: ./validate Reviewers: goldfire, austin, bgamari Subscribers: thomie, RyanGlScott Differential Revision: https://phabricator.haskell.org/D1738 GHC Trac Issues: #11341 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 12:50:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 12:50:17 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.f0c37f85296318de9d4f133522f4ddf4@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: merge Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T11341 Blocked By: | Blocking: Related Tickets: #10828 | Differential Rev(s): Phab:D1738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => merge * testcase: => th/T11341 Comment: This is now fixed in HEAD. It would be really good to have this in GHC 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 12:54:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 12:54:33 -0000 Subject: [GHC] #11308: haddock and Cabal regression In-Reply-To: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> References: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> Message-ID: <060.b2512176f77acd144799c0eaf9f4798a@haskell.org> #11308: haddock and Cabal regression -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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 => upstream Comment: I have merged the Haddock portion to both Haddock's `v2.16` and `master` branches and bumped the Haddock submodule. I am currently waiting on the Cabal part to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 14:50:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 14:50:38 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.52099840d43619d86b237ba1bedd6880@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | 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 Wed Jan 6 14:53:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 14:53:40 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.5bfdfe9a1f636f43e2c1618fb4df255b@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10946, #10045 | 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 Wed Jan 6 15:37:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 15:37:02 -0000 Subject: [GHC] #11359: Consider removing RelaxedLayout and friends Message-ID: <046.26f295ac88026e78626730eb2098b22e@haskell.org> #11359: Consider removing RelaxedLayout and friends -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These three parsing-related language extensions were [[https://ghc.haskell.org/trac/ghc/wiki/LanguagePragmaHistory|introduced]] some time ago yet are likely not used in the wild as they still are not registered in Cabal's language extension list (which Hackage uploads are checked against, see #8176), * `RelaxedLayout` (introduced in 7.2, prompted by #1060) * `AlternativeLayoutRule` (introduced in 7.0, reason unknown) * `AlternativeLayoutRuleTransitional` (introduced in 7.0, reason unknown) As far as [[https://mail.haskell.org/pipermail/ghc- devs/2013-September/002267.html|I can]] [[https://ghc.haskell.org/trac/ghc/ticket/8176#comment:10|tell]] no one knows the status of these, nor are they listed in the users guide. We should ask the community whether they would mind seeing these extensions vanish and remove them if not. If so then we should see to it that they are registered properly with Cabal so they can be used on Hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 15:37:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 15:37:34 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.dba9f16807515ac560c2477a047171e7@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #11359 to track the potential removal of these three layout language extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 15:37:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 15:37:38 -0000 Subject: [GHC] #11360: Test "termination" doesn't pass with reversed uniques Message-ID: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> #11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- It fails with (full trace https://phabricator.haskell.org/P80): {{{ *** Core Lint errors : in result of Tidy Core *** : warning: In the expression: ReplaceApply @ k_a18o1Q @ (Apply t1_X18o1T t2_X18o1O) @ n_a18o1O @ (Apply r1_X18o1Q r2_X18o1M) @ r2_X18o1M @ t2_X18o1O @ r1_X18o1Q @ t1_X18o1T @~ (_N :: Apply t1_X18o1T t2_X18o1O ~# Apply t1_X18o1T t2_X18o1O) @~ (_N :: Apply r1_X18o1Q r2_X18o1M ~# Apply r1_X18o1Q r2_X18o1M) dt_a18nR6 dt_a18nR5 Argument value doesn't match argument type: Fun type: (Apply r1_X18o1Q t2_X18o1O ~# Apply t1_X18o1T t2_X18o1O, Apply r1_X18o1Q r2_X18o1M ~# Apply r1_X18o1Q r2_X18o1M) => Replace k_a18o1Q t1_X18o1T n_a18o1O r1_X18o1Q -> Replace k_a18o1Q t2_X18o1O n_a18o1O r2_X18o1M -> Replace k_a18o1Q (Apply r1_X18o1Q t2_X18o1O) n_a18o1O (Apply r1_X18o1Q r2_X18o1M) Arg type: Apply t1_X18o1T t2_X18o1O ~# Apply t1_X18o1T t2_X18o1O Arg: CO: _N }}} Steps to reproduce: 1. Add line `TEST_HC_OPTS += -dinitial-unique=16777000 -dunique-increment=-1` after line `TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` in `mk/test.mk` 2. `make TESTS=termination` I suspect this is the same problem I'm running at https://mail.haskell.org/pipermail/ghc-devs/2016-January/010902.html, since the same change to `substTyWith` makes the test pass for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 15:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 15:46:30 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques Message-ID: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- It fails with: {{{ tc253.hs:23:7: error: ? Couldn't match type ?Maybe Int? with ?(String, Bool)? Expected type: Maybe Int -> (String, Int) -> Maybe Int Actual type: Fam Int Bool -> Fam Int Int -> Fam Int Bool ? In the expression: inc (undefined :: Int) In an equation for ?foo?: foo = inc (undefined :: Int) }}} Steps to reproduce: 1. Add line `TEST_HC_OPTS += -dinitial-unique=16777000 -dunique-increment=-1` after line `TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` in `mk/test.mk` 2. `make TESTS=tc253` I suspect this is related to #11148 since the symptoms are similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 15:51:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 15:51:20 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques Message-ID: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- It fails with (full trace https://phabricator.haskell.org/P81): {{{ *** Core Lint errors : in result of Tidy Core *** : warning: [in body of lambda with binder dt_a18nYf :: In f_a18o2M (Sum1 r_a18o2L (In ('F f_a18o2M) r_a18o2L)) o_a18o2K] Kind application error in coercion ?Sym (TFCo:R:InioFro[0] _N _N _N) _N _N? Function kind = Code (Sum i_a18nYD o_a18nYC) o_a18nYC -> * Arg kinds = [(o_a18o2K, o_a18nYC)] : warning: [in body of lambda with binder dt_a18nYf :: In f_a18o2M (Sum1 r_a18o2L (In ('F f_a18o2M) r_a18o2L)) o_a18o2K] Kind application error in coercion ?Sym (TFCo:R:InioFro[0] _N _N _N) _N _N? Function kind = Code (Sum i_a18nYD o_a18nYC) o_a18nYC -> * Arg kinds = [(o_a18o2K, o_a18nYC)] }}} Steps to reproduce: 1. Add line `TEST_HC_OPTS += -dinitial-unique=16777000 -dunique-increment=-1` after line `TEST_HC_OPTS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-$(GhcPackageDbFlag) -rtsopts $(EXTRA_HC_OPTS)` in `mk/test.mk` 2. `make TESTS=T6137` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 16:32:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 16:32:11 -0000 Subject: [GHC] #11360: Test "termination" doesn't pass with reversed uniques In-Reply-To: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> References: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> Message-ID: <061.c32e9c7f51375145c079f4534b6aa874@haskell.org> #11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 niteria): T5490 also fails in a similar way with uniques reversed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 16:39:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 16:39:42 -0000 Subject: [GHC] #11308: haddock and Cabal regression In-Reply-To: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> References: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> Message-ID: <060.e332feb5b45844f9ba8f95b43a63bb42@haskell.org> #11308: haddock and Cabal regression -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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 Ben Gamari ): In [changeset:"89ba83d981df3e56809440764cf81773bc33d00a/ghc" 89ba83d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89ba83d981df3e56809440764cf81773bc33d00a" Bump Cabal and Haddock to fix #11308 Bump Cabal and Haddock submodules such that they both support GCC-style response files on Windows. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:26:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:26:07 -0000 Subject: [GHC] #431: runInteractiveProcess and closed stdin. In-Reply-To: <045.572dbbd9b6b46d3f7b1e78158be38aba@haskell.org> References: <045.572dbbd9b6b46d3f7b1e78158be38aba@haskell.org> Message-ID: <060.08ad7727b1fb16aa04243930ec31d738@haskell.org> #431: runInteractiveProcess and closed stdin. -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: closed Priority: low | Milestone: ? Component: | Version: 6.4 libraries/process | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #5761 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5761 Comment: For reference, this was fixed in the following commits. https://github.com/haskell/process/commit/4a804c27f2c1a1d2f331006e32229c43750132be: {{{ Author: simonmar Date: Mon Aug 1 13:23:22 2005 +0000 [project @ 2005-08-01 13:23:22 by simonmar] Fix [ ghc-Bugs-1249226 ] runInteractiveProcess and closed stdin. }}} https://github.com/haskell/process/commit/9c553822abd15de9c1543820b8d9f070b00fb19f: {{{ Author: Simon Marlow Date: Fri May 23 10:07:40 2008 +0000 Overhall System.Process - fix #1780: pipes created by runInteractiveProcess are set close-on-exec by default - add a new, more general, form of process creation: createProcess Each of stdin, stdout and stderr may individually be taken from existing Handles or attached to new pipes. Also it has a nicer API (as discussed on libraries at haskell.org). - add readProcess / readProcessWithExitCode, originally from Don Stewart's newpopen package. These functions behave like C's popen(). - Move System.Cmd.{system,rawSystem} into System.Process. Later we can depecate System.Cmd. - Don't use O_NONBLOCK for pipes, as it can confuse the process attached to the pipe (requires a fix to GHC.Handle in the base package). - Provide a way to close all the file descriptors in the new process (see #1415) - add a couple more tests for the new features - bump the version to 2.0 }}} https://github.com/haskell/process/commit/3e6acdd0d9f7a80bbe454d114fb192e0a5a8008b: {{{ Author: Simon Marlow Date: Fri Dec 11 10:05:40 2009 +0000 Add comments re: #431 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:44:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:44:21 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.7b1597cd66c493af8900d8a297fc5687@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 niteria): It broke right after https://phabricator.haskell.org/rGHC6746549772c5cc0ac66c0fce562f297f4d4b80a2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:44:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:44:58 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.90dec24c466c4976d0af1ba5a247a16f@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "IOLoop.hs" added. Example loop in IO -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:46:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:46:01 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.5794a6351c92d80a98beb80d626fc608@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "IOLoop.simpl" added. Simplifier output (no suprises here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:46:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:46:52 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.30dff5f69ae7cc630633c32f39eb97b1@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "PureLoop.cmm" added. Generated cmm for pure version -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:47:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:47:18 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.f69c4faad55cd7f812812511b6db21ec@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "IOLoop.cmm" added. Generated cmm for IO version -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 17:59:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 17:59:57 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.67764dd0550a76fa01834975a688d4d8@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): > Interesting, though I don't yet understand the details. Could you boil out a standalone example that demonstrates just this single issue? I.e. two versions of a function, one of which repeats the stack check and one of which doesn't, and show the code side by side? If I understand cmm correctly, we jump to the start of $wa in line 34, so the IO version repeats the stack check. The corresponding instruction in the pure version is in line 33, here we jump to cCT, so behind our stack check. This should also be possible in the IO version as the function only uses constant stack space and if it was available once, it should stay available until we deallocate it, right? > > but it seems hard or impossible to correctly identity such unused arguments (I mean, it is used, but only in a function which does not use it...). > > Well GHC's strictness analyser should find exactly this case. I'm puzzled why it does not. Again, could you spare a moment to make a standalone reproducer for just this issue? Or at least a smallish function I can compile in isolation to see this argument not disappearing. > No, I did not mean the optimizer in this case. The unused argument is optimized out, I was just thinking whether GHC could warn if an argument is never used (as it does with unused variables), as this sometimes indicated unfinished code which should either be removed (or documented as such) or finished. But I think this comes with too many cases where you want an unused argument, either to pass in a type via proxy or to satisfy another functions expectations. And if a function is recursive, unused arguments have to be passed on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 18:20:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 18:20:37 -0000 Subject: [GHC] #11333: GHCi does not discharge satisfied constraints In-Reply-To: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> References: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> Message-ID: <066.bafb58abc6136281e2c753d02cc0784f@haskell.org> #11333: GHCi does not discharge satisfied constraints ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Iceland_jack): This error message can be improved, mention `TypeApplications` as a possible cause alone with monom. {{{#!hs Prelude> :set -XTypeApplications Prelude> data A Prelude> :t (==) @A (==) @A :: Eq A => A -> A -> Bool Prelude> a = (==) @A :4:1: error: ? No instance for (Eq A) arising from a use of ?==? ? When instantiating ?a?, initially inferred to have this overly-general type: Eq A => A -> A -> Bool NB: This instantiation can be caused by the monomorphism restriction. }}} `==@A` here is also not desirable. {{{#!hs % ghci -ignore-dot-ghci GHCi, version 8.1.20160102: http://www.haskell.org/ghc/ :? for help Prelude> data A Prelude> :t (==) @A :1:1: error: Pattern syntax in expression context: ==@A Did you mean to enable TypeApplications? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 18:42:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 18:42:07 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms In-Reply-To: <051.f6994676afcea2faaae7090f3210796a@haskell.org> References: <051.f6994676afcea2faaae7090f3210796a@haskell.org> Message-ID: <066.db7a2b58120b5982f40712566b25f110@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Unsure of pattern synonym scoping rules. > I want to be able to refer to a type in the signature (assuming `symbol` > from #11349): > > {{{#!hs > symbol :: forall s. KnownSymbol s => String > symbol = symbolVal @s Proxy > > -- Not in scope: type variable ?s? > -- Not in scope: type variable ?s? > pattern Symbol :: forall s. KnownSymbol s => String > pattern Symbol <- ((== symbol @s) -> True) where > Symbol = symbol @s > }}} > > Without `TypeApplications`: > > {{{#!hs > -- ? Could not deduce (KnownSymbol n0) > -- arising from a use of ?symbolVal? > -- from the context: KnownSymbol s > -- bound by the type signature for pattern synonym ?Symbol?: > -- String > pattern Symbol :: forall s. KnownSymbol s => String > pattern Symbol <- ((== symbolVal (Proxy :: Proxy s)) -> True) > }}} > > but it (GHCi, version 8.1.20160102) says the type variable `s` is not in > scope. The desired outcome would be something like (this touches on > ticket #11350): > > {{{#!hs > >>> Symbol @"blessed duck" > "blessed duck" > > isDuck :: String -> Bool > isDuck (Symbol @"duck") = True > isDuck _ = False > }}} > > With a nudge and a wink to #9671. New description: Unsure of pattern synonym scoping rules. I want to be able to refer to a type in the signature (assuming `symbol` from #11349): {{{#!hs symbol :: forall s. KnownSymbol s => String symbol = symbolVal @s Proxy -- Not in scope: type variable ?s? -- Not in scope: type variable ?s? pattern Symbol :: forall s. KnownSymbol s => String pattern Symbol <- ((== symbol @s) -> True) where Symbol = symbol @s }}} Without `TypeApplications`: {{{#!hs -- ? Could not deduce (KnownSymbol n0) -- arising from a use of ?symbolVal? -- from the context: KnownSymbol s -- bound by the type signature for pattern synonym ?Symbol?: -- String pattern Symbol :: forall s. KnownSymbol s => String pattern Symbol <- ((== symbolVal (Proxy :: Proxy s)) -> True) }}} but it (GHCi, version 8.1.20160102) says the type variable `s` is not in scope. Is this intentional? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 18:52:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 18:52:07 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.551ac0175f4083d4a062f6b430f98be6@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): Has this happened by any chance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 18:55:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 18:55:29 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.39989ad1e4ec4bf2d46f40e8ab922bd7@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 6.8.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:D395 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It would be great if at least this particular item could make it on to that list. In general it would be great to have a comprehensive summary of the committee's future plans. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 19:22:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 19:22:04 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.d7cad767e8e90c2174482f002db4da4d@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To collect some of the comments you've made in #8472 and #11292, is this what you want to be done? 1. Introduce a new `String#` type, and make primitive string literals their values, e.g., `"foo"# :: String#`. 2. Allow top-level `String#`s, e.g., {{{#!hs a::Addr# = "foo"# }}} but not top-level `String#` computations, which would entail: * Modify the test `isUnLiftedType ty` in `SetLevels.lvlMFE`, which stops unlifted things getting floated to top level. * Similarly `Simplify.bindingOk`. * Make `CmmLint` check the new invariant. * The STG->Cmm code generator would need to generate some suitable `CmmData` stuff. 3. Introduce primitive operations that manipulate `String#`s (e.g., a Haskell equivalent of `strcmp`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 19:27:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 19:27:51 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.b56b099dae54b783e2a990d8ddd5a7aa@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): Replying to [comment:2 jstolarek]: > Adding a new constructor will force TH clients to implement handling of infix constructors even in situations where they don't care about infixity, whereas adding a new field to `GadtC` will be simple to handle - programmers can simply ignore that field in situations where it is irrelevant. Fair enough. By that logic, we don't need `InfixC` either, but I'll avoid making breaking changes for now. Let's see if I can get this done by the 8.0 release?fingers crossed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 19:29:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 19:29:11 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.6c4cc295293459a8f79cf27cdacae16d@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:5 rwbarton]: > Word is basically useless as an "efficient small-ish Natural" for this reason, and only makes sense when you specifically want the machine- specific wrap-around behavior, or when doing bit manipulation only. A fixed-precision type with the underflow semantics of `Natural` could be useful. Anyway -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 19:33:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 19:33:42 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.afc1915603d9c1958bbd13272d494ff9@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): > So I think the algorithm must be this: always process a type instance declaration as soon as all the type constructors it mentions have been kind-checked. Yes I believe this is the way forward. Your description of the problem is spot on, and the third bullet is particularly important. With my patch, all `InstDecl`s (even data and class instances) enter the dependency graph. Every `InstDecl` depends upon its class or family and the `FreeVars` determined by the renamer, while every `TyClDecl` which mentions a type family or class depends also upon ''every'' one of its instances known to the renamer. But given the third bullet point, this method is too coarse; `type R = MK 'True` should ''not'' depend upon `type instance F R`. > Algorithmically, we can't just add the `type instance` declarations to the strongly-connected component analysis for type/class decls, because of the lack of explicit dependencies. As far as I can tell, there is enough information to add them, except when dealing with instances of imported families. Consider this example (from a note in the patch) {{{#!hs --A.hs type family Closed (t :: Type) :: Type where Closed t = Open t type family Open (t :: Type) :: Type -- B.hs import A data Q where Q :: Closed Bool -> Q type instance Open Int = Bool type S = 'Q 'True }}} We must ensure that `type instance Open Int = Bool` comes before `type S = 'Q 'True`, but `'Q` doesn't depend directly upon `Open`, and we don't know that `Closed` depends upon `Open`! Although we add `type instance Open Int` to the dependency graph, we don't have enough information to connect it with `type S`, but this is OK so long as we fulfil the aforementioned goal: > always process a type instance declaration as soon as all the type constructors it mentions have been kind-checked. In the patch, we achieve this by doing dependency analysis in two passes 1. Add a new "meta-node" dependent upon every `InstDecl`, and on which every `TyClDecl` depends. 2. Compute SCCs of this augmented graph. 3. For every SCC, remove the meta-node and recompute the SCC. 4. Concatenate these SCCs. If an `InstDecl` does not depend upon a `TyClDecl`, then it will appear in an SCC of the augmented graph ''before'' the SCC in which the `TyClDecl` appears, thanks to the made-up dependency of the `TyClDecl` on every `InstDecl`. I'm not sure I follow your description of the algorithm. The first bullet says we do SCC on the `TyClDecl`s, but the third point says that before we do this, we must process the `InstDecl`s. Did you mean that we keep SCC as is, with just `TyClDecl`s, and during type-checking of the groups, we ensure that when an `InstDecl`s dependencies are met, we check it immediately? That seems simpler and less invasive than my approach, and doesn't suffer from the problem shown by the third bullet. But it's not clear to me how to efficiently determine when an `InstDecl`s dependencies have been met. We wouldn't want to scan the entire set each time we process a `TyClDecl`, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 19:48:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 19:48:51 -0000 Subject: [GHC] #11363: Parser groups "::" and "*" together in kind signature (a::*) Message-ID: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> #11363: Parser groups "::" and "*" together in kind signature (a::*) -----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- Compare a session in 7.10 {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> data A (a :: *) = B :2:14: Illegal kind signature: ?*? Perhaps you intended to use KindSignatures In the data type declaration for ?A? Prelude> data A (a::*) = B :3:13: parse error on input ?)? }}} to a session in 8.1 {{{ GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help Prelude> data A (a :: *) = B :1:14: error: Illegal kind signature: ?*? Perhaps you intended to use KindSignatures In the data type declaration for ?A? Prelude> data A (a::*) = B :2:9: error: Unexpected type ?a ::*? In the data declaration for ?A? A data declaration should have form data A a = ... }}} GHC seems to group "::" and "*" together. Same with (?) from Data.Kind with TypeInType enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:07:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:07:55 -0000 Subject: [GHC] #11363: Parser groups "::" and "*" together in kind signature (a::*) In-Reply-To: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> References: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> Message-ID: <066.7cc12cd1d5019b377c8936f853c2e7e5@haskell.org> #11363: Parser groups "::" and "*" together in kind signature (a::*) --------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+--------------------------- Comment (by rwbarton): That seems sensible, since `::*` is a valid operator name. {{{ Prelude> :set -XTypeOperators Prelude> data a ::* b Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:17:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:17:04 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 Message-ID: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- The following code fragment works with GHCs prior to GHC 8.0 but not with GHC 8.0: {{{#!hs {-# LANGUAGE RoleAnnotations #-} {-# LANGUAGE IncoherentInstances #-} {-# LANGUAGE RankNTypes #-} module Issue where import Data.Coerce (coerce) data Proxy a = Proxy newtype Catch a = Catch a class Throws e type role Throws representational instance Throws (Catch e) newtype Wrap e a = Wrap { unWrap :: Throws e => a } coerceWrap :: Wrap e a -> Wrap (Catch e) a coerceWrap = coerce unthrow :: proxy e -> (Throws e => a) -> a unthrow _ = unWrap . coerceWrap . Wrap {- this works in GHC 7.10.3, but fails in GHC 8.0 with GHCi, version 8.0.0.20160105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Issue ( Issue.hs, interpreted ) Issue.hs:25:13: error: ? Could not deduce (Throws e) from the context: Throws e0 bound by a type expected by the context: Throws e0 => a at Issue.hs:26:13-38 Possible fix: add (Throws e) to the context of the type signature for: unthrow :: proxy e -> (Throws e => a) -> a ? In the expression: unWrap . coerceWrap . Wrap In an equation for ?unthrow?: unthrow _ = unWrap . coerceWrap . Wrap Failed, modules loaded: none. -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:20:11 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.b13e5f0f98d830b668c45b2cfd7c60c6@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 hvr): Changing the type-signature to {{{#!hs unthrow :: Throws e => proxy e -> (Throws e => a) -> a }}} In fact makes the code compile... but is this a regression or not? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:25:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:25:45 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.407b635b85319742d36050160905aebd@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett, core-libraries-committee (added) Comment: Let's separate two things: * Top-level unboxed string literals: #8472 * Not using `Addr#` for string literals: this ticket. Here's my summary for this ticket, after talking to Simon M. * It's plain wrong to use `Addr#` as the type of a string literal. If we do so, there is no reliable way to compute equality for {{{ data T = MkT Addr# deriving( Eq ) }}} Since the `Addr#` might come from `malloc` or something, it must compare using equality on `Addr#`. But then there is no guarantee that `MkT "foo"# == MkT "foo"#`. * So we need a new type for unlifted string literals, say `String#`. It could be primitive, and that's what I'll assume for now. * Of course the underlying representation will be the same as `Addr#`. But there should be no operation `get :: String# -> Addr#` (except maybe in the IO monad), else it'd possible that `get "foo"#` might be not-equal to `get "foo"#`. * What operations do we need on `String#`? Presumably at least {{{ eqString# :: String# -> String# -> Int# -- Like eqChar# cmpString# :: String# -> String# -> Int# -- 3-way compare lenString# :: String# -> Int# -- Number of chars indexString# :: String# -> Int# -> Char# -- Get the ith char }}} * NB: I'm deliberately not saying that the string is null-terminated. That's be up to the implementation of `String#`, provided it offered the above operations. A better representation might be a record of a length and a blob of bytes. * Could `String#` simply be a `ByteArray#`? {{{ type String# = ByteArray# }}} After all, `ByteArray#` already has primops `sizeOfByteArray#` and `indexCharArray#`. We'd just need a way to have a statically-allocated `ByteArray#`, but that would be an excellent thing anyway. e.g. I believe that Happy mis-uses literal strings to allow it to build a statically- allocated array. Avoiding yet another primitive type would be a relief. See also #5218 and #9577 * I'm not sure about how Unicode plays with all of this. * This would be a potentially breaking change for any code using unboxed string literals. I'm copying the Core Libraries Committee I'd love someone to take this up. there -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:31:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:31:57 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.6134b0a0d4d783bb710078b85e48cb42@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 hvr): Here's a blog post motivating this code (thanks Ben!): http://www.well-typed.com/blog/2015/07/checked-exceptions/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:32:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:32:15 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.7c410f88d8166610bf5d84f594ca7da4@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 bgamari): It may make it compile, but it breaks the intended semantics of `unthrow`. I would expect that this is a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:46:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:46:37 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.0c75ad70d6962aa981cf11611bdec1ce@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This test just needs a way to generate two different `Addr#`s so that it can test whether a derived Eq instance compares them correctly. Using string literals guarded by NOINLINE is one easy way to do that, and has the advantage (for the way the test is structured) of being pure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:49:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:49:17 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.b5a658311a496f5bce368f786002b693@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I suppose I could just replace the primitive string literals with `nullAddr#`, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:50:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:50:04 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.b9dd57e38ae6658cef64433b625c73d7@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't know, do you really only need one `Addr#`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:50:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:50:43 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.99caaf76984a481ac52bcb0c8f8b26cb@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 simonpj): * status: new => closed * resolution: => invalid Comment: I think that 7.10 is wrong. It generates this elaborated program {{{ unthrow = \ (@ a_anq) (@ e_anr) (@ (proxy_ans :: * -> *)) _ [Occ=Dead] -> . @ (Wrap (Catch e_anr) a_anq) @ a_anq !! @ (Throws e_anr => a_anq) (unWrap @ (Catch e_anr) @ a_anq (T11364.$fThrowsCatch @ e_anr)) (. @ (Wrap e_anr a_anq) @ (Wrap (Catch e_anr) a_anq) !! @ (Throws e_anr => a_anq) (coerceWrap @ e_anr @ a_anq) (\ (tpl_B1 :: Throws e_anr => a_anq) -> tpl_B1 `cast` (Sym (T11364.NTCo:Wrap[0] _R _R) :: (Throws e_anr => a_anq) ~R# Wrap e_anr a_anq))) }}} Look at the lines marked `!!`. We are instantiating `(.)` with a qualified type, which is never supposed to happen. (That's essentially impredicativity.) And if you eta-expand, you get the same error with 7.10 as you do with 8.0 {{{ unthrow :: forall aa ee proxy. proxy ee -> (Throws ee => aa) -> aa unthrow _ x = unWrap (coerceWrap (Wrap x)) }}} we get {{{ * Could not deduce (Throws ee) arising from a use of `x' from the context: Throws e0 }}} So I count that as a win: 8.0 is behaving more self-consistently. Moreover, there's a good reason for it. Look at the eta-expanded version. Nothing fixes the instantiation of `e` (namely `e0`) used for `Wrap` and `unWrap` to be the same `ee` that appears in the type signature for `unthrow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:53:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:53:01 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.f157f6dd15de94cee4bcc81fa74e1214@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): You can make it compile by adding a signature to fix `e0` to be `ee`. For example: {{{ unthrow :: forall aa ee proxy. proxy ee -> (Throws ee => aa) -> aa unthrow _ x = unWrap (coerceWrap (Wrap x :: Wrap ee aa)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:55:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:55:08 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.2e5256d6a755242c9deec0d4a05c9206@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): At the moment I'm only testing if something with unlifted types can be equal to itself, so one `Addr#` suffices. I could conceivably add a test for two things that aren't equal, in which the two unequal fields are something like `nullAddr#` and `plusAddr# 1# nullAddr#` (disclaimer: I don't know how safe that would be in general). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 20:59:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 20:59:19 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.d9cc5be26a05730e717e692ff1c088b8@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): Hm... I might have been a bit too optimistic in my timeframe estimate. I ran into a very tricky stumbling block when trying to implement this. Namely, what happens when you try to splice an infix `GadtC` into source code in `Convert.hs`? Unlike `InfixC`, the infixity of a GADT constructor depends on the presence of a user-supplied fixity declaration. But AFAIK, there's no way to look up what things have fixity declarations in `CvtM`. I suppose you could just ignore the declaration fixity field of `GadtC` during splicing. But then if you don't also splice in a corresponding fixity declaration, you might actually end up with a non-infix GADT constructor in the end, even if you marked it otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 21:09:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 21:09:58 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.085ee8b1d7174e8e4a070746a24e639b@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): Yes, exactly. That is ''much'' simpler than "meta-nodes", and had the great merit of being correct (see third bullet). I'm not too stressed about efficiency. You need only do this for the open type-family instances, and there are seldom zillions of them. If you want something a bit more efficient, try this: * Start with a set of pairs `(fam-inst-decl, free-vars)`, where `free- vars` is a list of ''locally-defined'' type/class constructors mentioned anywhere in the instance. I'll call them the **gate vars** of the fam- inst-decl. * Typecheck any instances whose gate list is empty. * Turn the set of pairs into a finite map as follows: for each pair `(fid, g:gs)`, add `g -> (fid, gs)` to the finite map. Tis is the **gate map**. * After typechecking a SCC of types/classes, take each one `T` in turn. Look up `T` in the gate map. For each `(fid, gs)` that it maps to, if `gs` is empty, that instance is ready to typecheck; if not, take one gate from `gs`. If it already in the type env, drop it and take another from `gs`. Once you find on active gate (i.e. not yet type-checked) and re-add the depleted pair to the gate map as before. That's it really. Essentially we cross off the gate vars one by one until none are left. You'd need to document this carefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 21:12:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 21:12:10 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms In-Reply-To: <051.f6994676afcea2faaae7090f3210796a@haskell.org> References: <051.f6994676afcea2faaae7090f3210796a@haskell.org> Message-ID: <066.d35f4d2d2192f1b228188d9867b61c18@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): You are right: scoped type variables from the pattern signature should scope, and they simply don't right now. That's a bug; or at least a serious inconsistency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 21:43:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 21:43:01 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.912e5a0211dabf769651a94c54044a72@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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 RyanGlScott): Actually, here's a better idea. My above comment shows that trying to encode whether a GADT constructor is declared infix directly into `GadtC` causes problems. But perhaps we don't need to do this. In theory, all we have to do is find out if there is a fixity declaration for the constructor. We're close to being able to do this in Template Haskell already through `reifyFixity`. The problem is that `reifyFixity` will return `defaultFixity` if it can't discover a user-defined fixity declaration for the argument, which leaves the programmer unable to know whether the user actually wrote that fixity, or if it's just `defaultFixity`. With a modest change to `reifyFixity`, {{{#!hs reifyFixity :: Name -> Maybe Fixity }}} where `Nothing` indicates the absence of a user-specified fixity declaration, then I think this would work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:09:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:09:19 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.405f2c8f4f0aa783767c6a24f93875aa@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7861a22561846eef9a6415a93d79e121dca9c05f/ghc" 7861a225/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7861a22561846eef9a6415a93d79e121dca9c05f" Add a note describing the protocol for adding a language extension Reviewers: hvr, thomie, austin Reviewed By: austin Subscribers: duncan Differential Revision: https://phabricator.haskell.org/D1741 GHC Trac Issues: #8176, #4437 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:09:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:09:19 -0000 Subject: [GHC] #4437: unregistered language extensions In-Reply-To: <045.ee6c715bbc21e9b184c2d75db75e9f98@haskell.org> References: <045.ee6c715bbc21e9b184c2d75db75e9f98@haskell.org> Message-ID: <060.f3aae4cf27074ca1f7923fff9f3daddc@haskell.org> #4437: unregistered language extensions -------------------------------------+--------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T4437 Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"7861a22561846eef9a6415a93d79e121dca9c05f/ghc" 7861a225/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7861a22561846eef9a6415a93d79e121dca9c05f" Add a note describing the protocol for adding a language extension Reviewers: hvr, thomie, austin Reviewed By: austin Subscribers: duncan Differential Revision: https://phabricator.haskell.org/D1741 GHC Trac Issues: #8176, #4437 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:19:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:19:56 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.b783cfe83bf6120a52710b3dc4a0196f@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "bench.tar.gz" added. Benchmark with original implementation, my changes and cdks changes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:26:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:26:25 -0000 Subject: [GHC] #11363: Parser groups "::" and "*" together in kind signature (a::*) In-Reply-To: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> References: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> Message-ID: <066.aa76fb7a73fec9d0ceb5d7e610e41802@haskell.org> #11363: Parser groups "::" and "*" together in kind signature (a::*) --------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+--------------------------- Comment (by Iceland_jack): Replying to [comment:1 rwbarton]: > That seems sensible, since `::*` is a valid operator name. Would the operator ever appear in that position (as a type/kind signature)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:29:47 -0000 Subject: [GHC] #11365: Worse performance with -O Message-ID: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> #11365: Worse performance with -O -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: optimization | Operating System: Unknown/Multiple performance concurrency | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The running time of the following program worsens when compiled with {{{-O}}}, and worsens more when compiled with ghc-7.10.2. {{{ #!haskell -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 3 seconds -- -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 11 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 5 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 13 seconds -- import Control.Concurrent import Control.Monad import Data.List main :: IO () main = do let x = foldl' (+) 0 [1 .. 100000000] mv <- newEmptyMVar replicateM_ 4 $ forkIO $ putMVar mv $! x nums <- replicateM 4 $ takeMVar mv print (nums :: [Integer]) }}} The following variant which doesn't share {{{x}}} improves with {{{-O}}} for ghc-7.10.2, but ghc-7.8.3 still produces a faster program. {{{ #!haskell -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 10 seconds -- -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 11 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 18 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 15 seconds -- import Control.Concurrent import Control.Monad import Data.IORef import Data.List main :: IO () main = do mv <- newEmptyMVar ref <- newIORef 0 replicateM_ 4 $ forkIO $ do i <- readIORef ref putMVar mv $! foldl' (+) i [1 .. 100000000] nums <- replicateM 4 $ takeMVar mv print (nums :: [Integer]) }}} Some related discussion [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010904.html here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:32:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:32:00 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.dcb04ff08f2dce8b669c40eafa0f07bd@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): I attached the modified benchmark from cdk which compares the current implementation found in base with cdks and my changes. Note that the {{{loopV_}}} function does not evaluate the returned results, so if someone wants to use that and makes {{{insertWith}}} somehow return its result lazy instead of in WHNF, these will be thrown away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:32:06 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.8b2de4738e7a3857d0f7434aca84b8cd@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 ezyang): Oops, this dropped off my plate. I'll do it soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:32:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:32:51 -0000 Subject: [GHC] #11363: Parser groups "::" and "*" together in kind signature (a::*) In-Reply-To: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> References: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> Message-ID: <066.b9625c62db7436bd88f742496c49d38c@haskell.org> #11363: Parser groups "::" and "*" together in kind signature (a::*) --------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+--------------------------- Comment (by rwbarton): Why does it matter? If `+` is a type operator and `::*` is a type operator and `data A (a +)` is a parse error then `data A (a ::*)` should be a parse error. Anything else seems terribly confusing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 22:36:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 22:36:17 -0000 Subject: [GHC] #11365: Worse performance with -O In-Reply-To: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> References: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> Message-ID: <071.b0acf17a2e8cde67d8e4255116eadc35@haskell.org> #11365: Worse performance with -O -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: optimization | performance concurrency 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 rwbarton): The "state hack" seems to be responsible here. Without `-O`, the argument to `replicateM_` is shared and therefore the expensive computation occurs only once. With `-O`, `replicateM_` is inlined and then due to the "state hack" GHC thinks it is okay to duplicate the expensive computation. Try building with `-fno-state-hack`. I made other small adjustments to the program in testing; you may also need `-fno-full-laziness`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 23:11:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 23:11:04 -0000 Subject: [GHC] #11366: Control.Exception.assert should perhaps take an implicit call stack Message-ID: <046.21258d69d9bdb9b22c24033dd849cd6b@haskell.org> #11366: Control.Exception.assert should perhaps take an implicit call stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It seems to me like our new implicit parameters-based callstack support is a more principled way of accomplishing the ad-hoc rewriting that we current do for `assert`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 23:24:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 23:24:24 -0000 Subject: [GHC] #11366: Control.Exception.assert should perhaps take an implicit call stack In-Reply-To: <046.21258d69d9bdb9b22c24033dd849cd6b@haskell.org> References: <046.21258d69d9bdb9b22c24033dd849cd6b@haskell.org> Message-ID: <061.c19a6b7a5fbe4703813d5f85ecf4e4a4@haskell.org> #11366: Control.Exception.assert should perhaps take an implicit call stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by gridaphobe): We actually do this already, but it's `assertError` that checks the assertion and gets the CallStack. GHC rewrites `assert` to `assertError` unless optimizations are enabled; `assert` is just `const id`. I suppose it would be consistent to give `assert` a CallStack too, but GHC will (rightly) complain that it's unused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 23:27:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 23:27:16 -0000 Subject: [GHC] Batch modify: #10137, #10788, #10677 Message-ID: <20160106232716.6F5B83A2FF@ghc.haskell.org> Batch modification to #10137, #10788, #10677 by thomie: milestone to 8.0.1 Action: leave -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 6 23:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jan 2016 23:28:55 -0000 Subject: [GHC] #11366: Control.Exception.assert should perhaps take an implicit call stack In-Reply-To: <046.21258d69d9bdb9b22c24033dd849cd6b@haskell.org> References: <046.21258d69d9bdb9b22c24033dd849cd6b@haskell.org> Message-ID: <061.82bf9731727a3ecf647947bcab16d274@haskell.org> #11366: Control.Exception.assert should perhaps take an implicit call stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by gridaphobe): To clarify, there are two kinds of rewriting that happen with `assert`. 1. Adding the source location. 2. Eliminating the assertion from "production" code. (1) is possible with implicit CallStacks, and is already done that way, (2) is a separate issue for which we don't have a more principled mechanism. But maybe we do, what about a rewrite rule? Those only fire when optimizations are enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:42:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:42:01 -0000 Subject: [GHC] #11367: [Regression] Pattern synonyms Message-ID: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> #11367: [Regression] Pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Regression. This worked in 7.10.2: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} pattern A :: Int -> String pattern A n <- (read -> n) where A 0 = "hi" A 1 = "bye" }}} Removing the final clause works in GHC head but given the same code it claims the clause is empty: {{{ % ghci -ignore-dot-ghci /tmp/tmp.t0h0pMgwWb.hs GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tmp.t0h0pMgwWb.hs, interpreted ) /tmp/tmp.t0h0pMgwWb.hs:4:9: error: pattern synonym 'where' clause cannot be empty In the pattern synonym declaration for: A Failed, modules loaded: none. Prelude> }}} The where clause is certainly not empty ? ironically seems to be caused by my very own #10426 ([https://phabricator.haskell.org/D1665 D1665]) :--) hoist by my own ticket as we say: {{{#!hs ; when (length matches /= 1) (wrongNumberErr loc) }}} Personally a trailing `where` is quite alright and handy when quickly checking if a declaration is otherwise OK. It works for data/newtype declarations as well as type classes. A workaround is to pattern match in other ways: {{{#!hs pattern A n <- ... where A = \case 0 -> "hi" 1 -> "bye" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:43:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:43:31 -0000 Subject: [GHC] #11367: [Regression] Pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.9f87ddd9a93366e566528c343597c29d@haskell.org> #11367: [Regression] Pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 Iceland_jack): Small note: When a pattern synonym is non-exhaustive its name is mangled: {{{ >>> A 3 "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive patterns in function $bA }}} It would be preferable to emit ?Non-exhaustive patterns in pattern synonym A?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:45:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:45:27 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms (was: [Regression] Pattern synonyms) In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.2925b1ea32eece9bc4b40c2413030c8c@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:48:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:48:14 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.301b7e1b3d01cc45d822e0bf403d8a25@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:53:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:53:32 -0000 Subject: [GHC] #10625: Spurious unused quantified type variable warning with ExistentialQuantification In-Reply-To: <050.bcfa2a8486244e674e467da363afe987@haskell.org> References: <050.bcfa2a8486244e674e467da363afe987@haskell.org> Message-ID: <065.39b892ed03bc3fd61b6f31dfc6632542@haskell.org> #10625: Spurious unused quantified type variable warning with ExistentialQuantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: fixed | ExistentialQuantification Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #5331 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I can't reproduce this anymore on GHC 8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:57:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:57:31 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.3924b75d6b4a9acb716851010a2fc060@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 mpickering): Please can you create another ticket for the wrong name in the error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 00:59:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 00:59:49 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.c3b14f4c10ad6db445994c29c2a6eb10@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 mpickering): > Personally a trailing where is quite alright and handy when quickly checking if a declaration is otherwise OK. I don't understand this comment. The trailing where indicates a bidirectional pattern synonym so you have to provide the builder as well as the matcher. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 01:07:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 01:07:43 -0000 Subject: [GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive Message-ID: <051.8288963528e24dfd4127278f265607de@haskell.org> #11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: #11367 Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------- {{{ pattern A n <- ... where A 0 = ... }}} When a pattern synonym is non-exhaustive its name is mangled: {{{ >>> A 3 "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive patterns in function $bA }}} ?Non-exhaustive patterns in pattern synonym A? [https://ghc.haskell.org/trac/ghc/ticket/11367?replyto=5#comment:1 Comment] from ticket #11367. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 01:39:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 01:39:58 -0000 Subject: [GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive In-Reply-To: <051.8288963528e24dfd4127278f265607de@haskell.org> References: <051.8288963528e24dfd4127278f265607de@haskell.org> Message-ID: <066.140a9915f3a099e1806e1242bed39d08@haskell.org> #11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------+--------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11367 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Description changed by Iceland_jack: Old description: > {{{ > pattern A n <- ... where > A 0 = ... > }}} > > When a pattern synonym is non-exhaustive its name is mangled: > > {{{ > >>> A 3 > "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive > patterns in function $bA > }}} > > ?Non-exhaustive patterns in pattern synonym A? > > [https://ghc.haskell.org/trac/ghc/ticket/11367?replyto=5#comment:1 > Comment] from ticket #11367. New description: {{{#!hs pattern A n <- ... where A 0 = ... }}} When a pattern synonym is non-exhaustive its name is mangled: {{{ >>> A 3 "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive patterns in function $bA }}} ?Non-exhaustive patterns in pattern synonym A? [https://ghc.haskell.org/trac/ghc/ticket/11367?replyto=5#comment:1 Comment] from ticket #11367. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 01:46:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 01:46:11 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.f675d4b11e0921f4ac20a5bf4d6acca9@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack: Old description: > Regression. This worked in 7.10.2: > > {{{#!hs > {-# LANGUAGE PatternSynonyms, ViewPatterns #-} > > pattern A :: Int -> String > pattern A n <- (read -> n) where > A 0 = "hi" > A 1 = "bye" > }}} > > Removing the final clause works in GHC head but given the same code it > claims the clause is empty: > > {{{ > % ghci -ignore-dot-ghci /tmp/tmp.t0h0pMgwWb.hs > GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/tmp.t0h0pMgwWb.hs, interpreted > ) > > /tmp/tmp.t0h0pMgwWb.hs:4:9: error: > pattern synonym 'where' clause cannot be empty > In the pattern synonym declaration for: A > Failed, modules loaded: none. > Prelude> > }}} > > The where clause is certainly not empty ? ironically seems to be caused > by my very own #10426 ([https://phabricator.haskell.org/D1665 D1665]) > :--) hoist by my own ticket as we say: > > {{{#!hs > ; when (length matches /= 1) (wrongNumberErr loc) > }}} > > Personally a trailing `where` is quite alright and handy when quickly > checking if a declaration is otherwise OK. It works for data/newtype > declarations as well as type classes. A workaround is to pattern match in > other ways: > > {{{#!hs > pattern A n <- ... where > A = \case > 0 -> "hi" > 1 -> "bye" > }}} New description: Regression. This worked in 7.10.2: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} pattern A :: Int -> String pattern A n <- (read -> n) where A 0 = "hi" A 1 = "bye" }}} Removing the final clause works in GHC head but given the same code it claims the clause is empty: {{{ % ghci -ignore-dot-ghci /tmp/tmp.t0h0pMgwWb.hs GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tmp.t0h0pMgwWb.hs, interpreted ) /tmp/tmp.t0h0pMgwWb.hs:4:9: error: pattern synonym 'where' clause cannot be empty In the pattern synonym declaration for: A Failed, modules loaded: none. Prelude> }}} The where clause is certainly not empty ? ironically seems to be caused by my very own #10426 ([https://phabricator.haskell.org/D1665 D1665]) :--) hoist by my own ticket as we say: {{{#!hs ; when (length matches /= 1) (wrongNumberErr loc) }}} Personally a trailing `where` is quite alright and handy when quickly checking if a declaration is otherwise OK. It works for data declarations as well as type classes. A workaround is to pattern match in other ways: {{{#!hs pattern A n <- ... where A = \case 0 -> "hi" 1 -> "bye" }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 01:54:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 01:54:30 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.228596054ef7052b94767bac2a4d8b81@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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: | -------------------------------------+------------------------------------- Old description: > Regression. This worked in 7.10.2: > > {{{#!hs > {-# LANGUAGE PatternSynonyms, ViewPatterns #-} > > pattern A :: Int -> String > pattern A n <- (read -> n) where > A 0 = "hi" > A 1 = "bye" > }}} > > Removing the final clause works in GHC head but given the same code it > claims the clause is empty: > > {{{ > % ghci -ignore-dot-ghci /tmp/tmp.t0h0pMgwWb.hs > GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /tmp/tmp.t0h0pMgwWb.hs, interpreted > ) > > /tmp/tmp.t0h0pMgwWb.hs:4:9: error: > pattern synonym 'where' clause cannot be empty > In the pattern synonym declaration for: A > Failed, modules loaded: none. > Prelude> > }}} > > The where clause is certainly not empty ? ironically seems to be caused > by my very own #10426 ([https://phabricator.haskell.org/D1665 D1665]) > :--) hoist by my own ticket as we say: > > {{{#!hs > ; when (length matches /= 1) (wrongNumberErr loc) > }}} > > Personally a trailing `where` is quite alright and handy when quickly > checking if a declaration is otherwise OK. It works for data declarations > as well as type classes. A workaround is to pattern match in other ways: > > {{{#!hs > pattern A n <- ... where > A = \case > 0 -> "hi" > 1 -> "bye" > }}} New description: Regression. This worked in 7.10.2: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} pattern A :: Int -> String pattern A n <- (read -> n) where A 0 = "hi" A 1 = "bye" }}} Removing the final clause works in GHC head but given the same code it claims the clause is empty: {{{ % ghci -ignore-dot-ghci /tmp/tmp.t0h0pMgwWb.hs GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tmp.t0h0pMgwWb.hs, interpreted ) /tmp/tmp.t0h0pMgwWb.hs:4:9: error: pattern synonym 'where' clause cannot be empty In the pattern synonym declaration for: A Failed, modules loaded: none. Prelude> }}} The where clause is certainly not empty ? ironically seems to be caused by my very own #10426 ([https://phabricator.haskell.org/D1665 D1665]) :--) hoist by my own ticket as we say: {{{#!hs ; when (length matches /= 1) (wrongNumberErr loc) }}} Personally a trailing `where` is quite alright and handy when quickly checking if a declaration is otherwise OK. It works for data/newtype declarations as well as type classes. A workaround is to pattern match in other ways: {{{#!hs pattern A n <- ... where A = \case 0 -> "hi" 1 -> "bye" }}} -- Comment (by Iceland_jack): Replying to [comment:4 mpickering]: > Please can you create another ticket for the wrong name in the error message. Done #11368 Replying to [comment:5 mpickering]: > > Personally a trailing where is quite alright and handy when quickly checking if a declaration is otherwise OK. > > I don't understand this comment. The trailing where indicates a bidirectional pattern synonym so you have to provide the builder as well as the matcher. It was poorly explained. My ''personal'' preference: {{{#!hs -- Unidirectional pattern A <- 'a' pattern A <- 'a' where -- Bidirectional pattern A <- 'a' where A = undefined pattern A <- 'a' where A = 'a' }}} I want to fail ASAP if I've made a mistake, I enjoy being able to compile ?under-construction? code. All of these declarations compile (with creatively chosen extensions) {{{#!hs data A data A a data A (a :: Type) data A (a :: Type) :: Type data A (a :: Type) :: Type where class B class B a class B (a :: Type) class Show a => B (a :: Type) class Show a => B (a :: Type) where }}} Why I brought it up: for pattern synonyms that ''will'' be bidirectional I often add the `where` out of habit from data/class: compiler complains and I (erase where/compile/add where/add dummy clause/compile/...) or (keep where/add dummy clause/compile/...). It sounds minor (and it is!) but it adds to the cognitive load. While coding I don't like thinking ?wait, did XYZ allow a where or not??, reverting back to a well-formed declaration if I got it wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 03:45:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 03:45:40 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.4874eb9a484f873ea0c31fd2a3390f8d@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1744 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:14:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:14:42 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.6c4fd5798e3c29c193a010d50393d2c9@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:16:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:16:56 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes Message-ID: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- The technique described in http://www.well-typed.com/blog/2015/07/checked-exceptions/ makes use of a class without any methods, i.e. {{{#!hs class Throws e }}} However, this by definition results in redundant constraints, e.g. {{{#!hs readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} which GHC 8.0 warns about. I propose to suppress warnings in case a class which has no methods is used as seemingly redundant constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:23:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:23:52 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.e8c50c7ca12c174b9e93fbad2f5f3e8c@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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 edsko): We could probably work around this by adding a dummy class method in `Throws` and call that in `throwChecked`. (But I think there are other use cases of method-less classes out there in the wild :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:36:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:36:25 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.c2f3e03055bfd00ba65bb857b8998d9f@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a5cea73c658888e01c162723d3e0e1439514ecdb/ghc" a5cea73c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5cea73c658888e01c162723d3e0e1439514ecdb" Turn AThing into ATcTyCon, in TcTyThing This change tidies up and simplifies (a bit) the knot-tying when kind-checking groups of type and class declarations. The trouble (shown by Trac #11356) was that we wanted an error message (a kind-mismatch) that involved a type mentioned a (AThing k), which blew up. Since we now seem to have TcTyCons, I decided to use them here. It's still not great, but it's easier to understand and more robust. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:36:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:36:25 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.f4c7c585c41438cbc0dcc906c878b2c8@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9915b6564403a6d17651e9969e9ea5d7d7e78e7f/ghc" 9915b656/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9915b6564403a6d17651e9969e9ea5d7d7e78e7f" Make demand analysis understand catch As Trac #11222, and #10712 note, the strictness analyser needs to be rather careful about exceptions. Previously it treated them as identical to divergence, but that won't quite do. See Note [Exceptions and strictness] in Demand, which explains the deal. Getting more strictness in 'catch' and friends is a very good thing. Here is the nofib summary, keeping only the big ones. -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- fasta -0.1% -6.9% -3.0% -3.0% +0.0% hpg -0.1% -2.0% -6.2% -6.2% +0.0% maillist -0.1% -0.3% 0.08 0.09 +1.2% reverse-complem -0.1% -10.9% -6.0% -5.9% +0.0% sphere -0.1% -4.3% 0.08 0.08 +0.0% x2n1 -0.1% -0.0% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -0.2% -10.9% -17.4% -17.3% +0.0% Max -0.0% +0.0% +4.3% +4.4% +1.2% Geometric Mean -0.1% -0.3% -2.9% -3.0% +0.0% On the way I did quite a bit of refactoring in Demand.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:36:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:36:25 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.c7ed3b50e6691c46b195845166176352@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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 Simon Peyton Jones ): In [changeset:"9915b6564403a6d17651e9969e9ea5d7d7e78e7f/ghc" 9915b656/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9915b6564403a6d17651e9969e9ea5d7d7e78e7f" Make demand analysis understand catch As Trac #11222, and #10712 note, the strictness analyser needs to be rather careful about exceptions. Previously it treated them as identical to divergence, but that won't quite do. See Note [Exceptions and strictness] in Demand, which explains the deal. Getting more strictness in 'catch' and friends is a very good thing. Here is the nofib summary, keeping only the big ones. -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- fasta -0.1% -6.9% -3.0% -3.0% +0.0% hpg -0.1% -2.0% -6.2% -6.2% +0.0% maillist -0.1% -0.3% 0.08 0.09 +1.2% reverse-complem -0.1% -10.9% -6.0% -5.9% +0.0% sphere -0.1% -4.3% 0.08 0.08 +0.0% x2n1 -0.1% -0.0% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -0.2% -10.9% -17.4% -17.3% +0.0% Max -0.0% +0.0% +4.3% +4.4% +1.2% Geometric Mean -0.1% -0.3% -2.9% -3.0% +0.0% On the way I did quite a bit of refactoring in Demand.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 08:50:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 08:50:55 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.b8407bce619087822ddf384549f21cf1@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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): Well in normal code you can't write {{{ f :: Int -> Int }}} and omit the declaration of `f`. You have to write {{{ f :: Int -> Int f = undefined }}} So it's consistent to require the same for pattern synonyms. Usually `where` clauses contain zero or more bindings, which is why an empty `where` is usually ok. But here it must contain exactly one. (Two would not make sense either.) For my money, I think it's maybe a mistake for the unidirectional/bidirectional split to be so quietly signaled. One could imagine {{{ pattern unidirectional Q a = pat pattern bidirectional P a b = pat pattern bidirectional R x = pat where R = ... }}} But opinions vary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:12:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:12:54 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.9496bba8ddf99356664b618b5fb74bb6@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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 simonpj): I'd be ok with that. But I suggest suppressing only if it has no methods ''and'' no superclasses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:14:13 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.7a07f979aad32f7e851609308a1625e2@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11356 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T11356 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:14:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:14:31 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.071b0425273ef863a3b0049aa98af837@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11356 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:14:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:14:48 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.d67f0ada2d6545d727bf78ba6049c3da@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:17:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:17:04 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.68b2fed5a94a27aa45c6d58d4f483aae@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11347 Blocked By: | Blocking: Related Tickets: #10946, #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T11347 * status: new => merge Comment: Done. I put the wrong ticket number in the commit, but this is it {{{ commit 02c1c5735aff0cce2b04a6b3e4732d62bb0a4f3c Author: Simon Peyton Jones Date: Wed Jan 6 17:22:02 2016 +0000 Use an Implication in 'deriving' error Trac #11437 showed that erroneous constraints from a 'deriving' clause need to be wrapped in an Implication to properly scope their skolems. The main change is in TcDeriv.simplifyDeriv; the call to buildImplicationFor is new. >--------------------------------------------------------------- 02c1c5735aff0cce2b04a6b3e4732d62bb0a4f3c compiler/typecheck/TcDeriv.hs | 23 +++++++++++++++------ compiler/typecheck/TcInstDcls.hs | 2 +- compiler/typecheck/TcPatSyn.hs | 2 +- compiler/typecheck/TcRnTypes.hs | 11 +++++++++- .../tests/deriving/should_compile/T10561.stderr | 8 +++++--- testsuite/tests/deriving/should_fail/T7148.stderr | 24 +++++++++++++--------- .../tests/typecheck/should_fail/T11347.stderr | 13 ++++++++++-- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:17:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:17:11 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.f8e3a0e1a302426c5d17ff3366c22ba9@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11347 Blocked By: | Blocking: Related Tickets: #10946, #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:33:12 -0000 Subject: [GHC] #10625: Spurious unused quantified type variable warning with ExistentialQuantification In-Reply-To: <050.bcfa2a8486244e674e467da363afe987@haskell.org> References: <050.bcfa2a8486244e674e467da363afe987@haskell.org> Message-ID: <065.a02c7d12842a5eb57088d94c59f88958@haskell.org> #10625: Spurious unused quantified type variable warning with ExistentialQuantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: fixed | ExistentialQuantification Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #5331 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1ee92293651c0cc70504df1a4450febb986ad891/ghc" 1ee9229/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ee92293651c0cc70504df1a4450febb986ad891" Test Trac #10625 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:33:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:33:28 -0000 Subject: [GHC] #10625: Spurious unused quantified type variable warning with ExistentialQuantification In-Reply-To: <050.bcfa2a8486244e674e467da363afe987@haskell.org> References: <050.bcfa2a8486244e674e467da363afe987@haskell.org> Message-ID: <065.97317e2702420767623bff93a26c3fae@haskell.org> #10625: Spurious unused quantified type variable warning with ExistentialQuantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: fixed | ExistentialQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | rename/should_compile/T10625 Blocked By: | Blocking: Related Tickets: #5331 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_compile/T10625 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:50:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:50:59 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.4bd3f6f739b87bb89dfe6c158559a9c5@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: jstolarek (added) Comment: OK I've had a look. * I have not looked at, or tried to reproduce, the benchmark. Probably we can just trust you. Let's just commit your improved code to the library. Ben? * That leaves the question of pure vs IO loop, which I think you are saying is the cause of the performance difference. Have you benchmarked that separately? (Your `IOLoop.hs` program, that is.) * It is indeed very odd that the "IO loop" does not generate as good code as the "pure loop". I believe that for the pure loop we are getting a C-- optimisation that turns a tail call into a jump to a label, so called "loopification". But this isn't happening for IO loop. I've collected info about loopification here: [wiki:Commentary/Compiler/Loopification]. I'm copying Jan Stolarek who was the last person to work on this. It'd be great to return to it. It'd be good to pull out this particular loopification issue into a new ticket, if you could. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 09:54:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 09:54:58 -0000 Subject: [GHC] #11365: Worse performance with -O In-Reply-To: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> References: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> Message-ID: <071.bac3e859a41a48f5b185d89a0874b8e4@haskell.org> #11365: Worse performance with -O -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: optimization | performance concurrency 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): Ah yes! Just search for "`replicateM`" and you'll see a raft of tickets about this one problem! If someone would like to dig further, I'd be happy to help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:11:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:11:21 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.28747294c77c09085e563b5e52c05267@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): See #11365 for another example, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:13:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:13:04 -0000 Subject: [GHC] #11365: Worse performance with -O In-Reply-To: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> References: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> Message-ID: <071.b086b6752529086e434bf981389cf4b9@haskell.org> #11365: Worse performance with -O -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: optimization | performance concurrency 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 nomeata): #1168 has a list of related tickets, and #9388 has ideas and preliminary work on how to limit the scope of the hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:52:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:52:08 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.189961dbc65346ec56008ea7f5644289@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10376 | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:52:34 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.0bf7863e9c36864fec61fbf1df438e51@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:52:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:52:46 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.f5eada3367e0a400efdc180e953bd219@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: python Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:53:30 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." In-Reply-To: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> References: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> Message-ID: <061.2ffeb2bc768e1372fb83dd68c5dffd5f@haskell.org> #11190: Hello "schedule: re-entered unsafely." ----------------------------------+------------------------------ Reporter: Chobbes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #951, #9920 | 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 Thu Jan 7 10:53:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:53:42 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." In-Reply-To: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> References: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> Message-ID: <061.91336a80805735b32682a1282a81fc60@haskell.org> #11190: Hello "schedule: re-entered unsafely." ----------------------------------+------------------------------ Reporter: Chobbes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #951, #9920 | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:54:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:54:20 -0000 Subject: [GHC] #8652: Cross-compiling broken for ARM/Linux target In-Reply-To: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> References: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> Message-ID: <061.27d53d5f559ea30b10c1f3ba9d032be2@haskell.org> #8652: Cross-compiling broken for ARM/Linux target ----------------------------------------+------------------------------ Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 10:58:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 10:58:09 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.1cfbe651db14892cf64b01ea263f023c@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact 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 varosi): Is it possible for GHC 8.x (major version change) to brake this, so it could parse ".xx" floats are most languages do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 11:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 11:15:34 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.c12019de054ce534ab3bd026607d8584@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact 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 ekmett): GHC doesn't specify the language report, so it renumbering to 8.x is irrelevant to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 11:30:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 11:30:43 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.f586b2e95724f75e4795a3a10d45c53b@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I finally had a moment to take a closer look at the code and I have some concerns. Most importantly, I don't understand how we can actually have infix GADT constructors. Splicing creates an `HsDecl.ConDecl` data type, which can be either `ConDeclGADT` or `ConDeclH98`. The latter constructor has field `con_details :: HsConDeclDetails name`, where `HsConDeclDetails` is a type synonym to: {{{#!hs data HsConDetails arg rec = PrefixCon [arg] -- C p1 p2 p3 | RecCon rec -- C { x = p1, y = p2 } | InfixCon arg arg -- p1 `C` p2 }}} There is no such field in `ConDeclGADT` data constructor, so how can we mark a constructor declaration as infix? You're asking: > what happens when you try to splice an infix `GadtC` into source code in `Convert.hs`? Indeed, what should happen in such a situation? I believe we should splice a normal GADT constructor because we have no way of expressing the infixity. Ryan, you also said in an earlier comment: > A GADT constructor is only considered to be declared infix if (a) it is an operator symbol, (b) it has two arguments, (c) it has a fixity declaration. Can you show me where this happens in code? Your ticket reports actual problems in the implementation but I am not sure that the way you trying to address them is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 11:38:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 11:38:12 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults In-Reply-To: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> References: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> Message-ID: <065.2e38ed4c30d3a1d77e590cd7897646fa@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 8024 | Differential Rev(s): Wiki Page: | -------------------------------------+--------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 11:38:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 11:38:25 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults In-Reply-To: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> References: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> Message-ID: <065.92c5e848f4f231d6eafce82a6bc7ed4d@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 8024 | Differential Rev(s): Wiki Page: | -------------------------------------+--------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 11:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 11:56:14 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.740d17c2f0dbfc009e6c7f5ffbe999fc@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 niteria): * owner: => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:00:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:00:10 -0000 Subject: [GHC] Batch modify: #10289, #10750, #9430, #10359, #10129 Message-ID: <20160107120010.C34083A2FF@ghc.haskell.org> Batch modification to #10289, #10750, #9430, #10359, #10129 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:14:33 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.4fbba0e4e2c46fc5d847df1d97185aad@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 jstolarek]: > There is no such field in `ConDeclGADT` data constructor, so how can we mark a constructor declaration as infix? This was my mistake. I thought that infix GADT constructors were marked with their own constructor ''? la'' `InfixCon`, but that turns out not to be the case. Instead, GHC simply checks for three properties in a generalized `PrefixCon`. > > what happens when you try to splice an infix `GadtC` into source code in `Convert.hs`? > > Indeed, what should happen in such a situation? I believe we should splice a normal GADT constructor because we have no way of expressing the infixity. Luckily, we don't need to express the infixity directly in the `GadtC`, as it suffices to splice in a `GadtC` with a symbol name and exactly two arguments, plus a separate fixity declaration. GHC takses care of the rest (see the test case in Phab:D1744 for proof). > > A GADT constructor is only considered to be declared infix if (a) it is an operator symbol, (b) it has two arguments, (c) it has a fixity declaration. > > Can you show me where this happens in code? These are checked via [https://git.haskell.org/ghc.git/blob/c78fedde7055490ca6f6210ada797190f3c35d87:/compiler/typecheck/TcTyClsDecls.hs#l1469 tcConIsInfixGADT]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:15:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:15:31 -0000 Subject: [GHC] Batch modify: #10625, #11292, #10716, #10361, #10927, #10846, ... Message-ID: <20160107121531.EEE963A2FF@ghc.haskell.org> Batch modification to #10625, #11292, #10716, #10361, #10927, #10846, #11122, #11283, #11233, #11255, #10619, #10589, #10432, #11039, #10897, #10362, #11137, #11265, #11274, #10426, #10982, #11225, #10697, #5217 by thomie: milestone to 8.0.1 Action: leave -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:33:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:33:08 -0000 Subject: [GHC] Batch modify: #10039, #10318, #11232, #11237, #10636, #11185, ... Message-ID: <20160107123308.629F13A2FF@ghc.haskell.org> Batch modification to #10039, #10318, #11232, #11237, #10636, #11185, #9632, #10819, #11053, #11194, #10785, #9017, #9389, #11192, #11187, #6119, #11155, #9706, #11016, #11148, #11144, #10896, #10839, #11132, #10836, #11136, #11105, #11112, #11119, #10970, #9651 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:41:32 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.614fbcf625fbda84b300d4315f96c0d9@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:41:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:41:39 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.05d125f2b07b04b653ef3c61daa78e61@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: invalid | Keywords: undefined, | place holder, posttctype Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:47:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:47:55 -0000 Subject: [GHC] Batch modify: #10900, #10622, #10734, #9591, #11038, #11010, ... Message-ID: <20160107124755.E2E583A2FF@ghc.haskell.org> Batch modification to #10900, #10622, #10734, #9591, #11038, #11010, #10979, #10149, #10267, #10714, #10939, #10868, #365, #10926, #10777, #10475, #10907, #10867 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:55:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:55:41 -0000 Subject: [GHC] Batch modify: #10837, #10580, #9912, #9782, #9855, #9710, ... Message-ID: <20160107125541.C30F83A2FF@ghc.haskell.org> Batch modification to #10837, #10580, #9912, #9782, #9855, #9710, #10849, #10486, #8596, #10775, #10762, #10805 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 12:57:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 12:57:47 -0000 Subject: [GHC] #10744: Allow oneShot to work with unboxed types In-Reply-To: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> References: <043.1a18f79737236ccee17a4841dc4bdcd8@haskell.org> Message-ID: <058.508e14745effc7751f5ca78808f1fcc0@haskell.org> #10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1136 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:04:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:04:22 -0000 Subject: [GHC] Batch modify: #10558, #10567, #10742, #10540, #10753, #10609, ... Message-ID: <20160107130422.72E943A2FF@ghc.haskell.org> Batch modification to #10558, #10567, #10742, #10540, #10753, #10609, #10721, #10615, #10704, #10706, #10694, #10586, #10134, #8253, #10522 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:12:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:12:46 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.f52779f4ee97cb669256d07cf69aeb5c@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 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:D606 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Compile-time performance bug * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:18:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:18:30 -0000 Subject: [GHC] #11360: Test "termination" doesn't pass with reversed uniques In-Reply-To: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> References: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> Message-ID: <061.2da6b0775b2806288449274c911f379f@haskell.org> #11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 niteria): * owner: => goldfire Comment: Bisects to https://phabricator.haskell.org/rGHC6746549772c5cc0ac66c0fce562f297f4d4b80a2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:18:59 -0000 Subject: [GHC] Batch modify: #10670, #10632, #10463, #10570, #10561, #10351, ... Message-ID: <20160107131859.4B2833A2FF@ghc.haskell.org> Batch modification to #10670, #10632, #10463, #10570, #10561, #10351, #9665, #10573, #10414, #10519, #10569, #10420, #10503, #10533, #10211, #10485, #10474, #10461, #10466, #10423, #8292 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:19:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:19:43 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.2ad81cf365347b09edc1cd87eeb25af3@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 niteria): * owner: => goldfire Comment: Bisects to https://phabricator.haskell.org/rGHC6746549772c5cc0ac66c0fce562f297f4d4b80a2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:31:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:31:55 -0000 Subject: [GHC] Batch modify: #8555, #8799, #9131 Message-ID: <20160107133155.B6DCE3A2FF@ghc.haskell.org> Batch modification to #8555, #8799, #9131 by thomie: Action: leave Comment: For future reference: commit 0cc47eb90805f3e166ac4d3991e66d3346ca05e7 {{{ Author: Richard Eisenberg Date: Fri Dec 12 17:19:21 2014 -0500 Rewrite `Coercible` solver Summary: This is a rewrite of the algorithm to solve for Coercible "instances". A preliminary form of these ideas is at https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver The basic idea here is that the `EqPred` constructor of `PredTree` now is parameterised by a new type `EqRel` (where `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can now talk about nominal equality (the usual case) or representational equality (the `Coercible` case). This is a change from the previous behavior where `Coercible` was just considered a regular class with a special case in `matchClassInst`. Because of this change, representational equalities are now canonicalized just like nominal ones, allowing more equalities to be solved -- in particular, the case at the top of #9117. A knock-on effect is that the flattener must be aware of the choice of equality relation, because the inert set now stores both representational inert equalities alongside the nominal inert equalities. Of course, we can use representational equalities to rewrite only within another representational equality -- thus the parameterization of the flattener. A nice side effect of this change is that I've introduced a new type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness in the flattener. This commit includes some refactoring as discussed on D546. It also removes the ability of Deriveds to rewrite Deriveds. This fixes bugs #9117 and #8984. Reviewers: simonpj, austin, nomeata Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D546 GHC Trac Issues: #9117, #8984 }}} -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:40:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:40:26 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.01fbaa322f698db6bdc6bfb814130b7a@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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 ekmett): Note: Suppressing only in the absence of superclasses means that any class constraint that just gives you a law will **always** spring this warning. {{{#!hs class Bifunctor p => Braided p where braid :: p a b -> p b a -- | @braid . braid = id@ class Braided p => Symmetric p swap :: Symmetric p => p a b -> p b a swap = braid }}} (This code is slightly simplified from http://hackage.haskell.org/package/categories-1.0.7/docs/Control-Category- Braided.html) One "solution" here is to move `swap` into the `Symmetric` class, but then you need to worry about it being overridden to be different than `braid`, which operationally can't happen in the current approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:44:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:44:35 -0000 Subject: [GHC] Batch modify: #10407, #10384, #9851, #10306, #10121, #10325, ... Message-ID: <20160107134435.3B7233A2FF@ghc.haskell.org> Batch modification to #10407, #10384, #9851, #10306, #10121, #10325, #10281, #10180, #10265, #9958, #10191 by thomie: milestone to 8.0.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:53:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:53:47 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" Message-ID: <045.3571b52d282565941cbfe29e22050176@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These redundant constraint warnings being in -Wall make it seemingly impossible for us to live up to the '3 Release Policy' in many situations. https://prime.haskell.org/wiki/Libraries/3-Release-Policy Consider the AMP: `(Monad m, Functor m)` gets used as a replacement for `Monad m` in many situations for compatibility with code before GHC 7.8, where that wants to call both `fmap` and something from `Monad`, but from 7.10+ that `Functor` is a redundant constraint. We have no backwards- facing 3-release-compatible constraint that someone could use in a type signature without warning to get both `fmap` and `return` that won't trigger this warning. Similarly if we split a class we can't advocate that folks use the subclass until the superclass is widely available or they'll get spammed with warnings. This affects splitting out `Semigroup` from `Monoid`. A similar issue arises with the `MonadFail` proposal as there is a stage around 8.4 where the 3-release-compatible advice would be to incur a `MonadFail` constraint, even when the active desguaring will be through `Monad`. I don't actually have a fix from the libraries side for the fact that with these showing up in -Wall, the 3 release policy doesn't work. Every single proposal the core libraries committee currently has in the works (except for adding `log1p`, `expm1`, etc. to Floating) is affected by this concern. One possible fix is to demote the redundant superclass warnings out of `-Wall`. This would resolve #11369 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:55:04 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.6e79766e07affdc6c7d1c679d0090b20@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * related: => #11370 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:55:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:55:18 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.a324a339361585783727e664b697f5d8@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:55:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:55:42 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.ca879344c045ff6a6d6a8c5d576ff3b1@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 13:57:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 13:57:20 -0000 Subject: [GHC] #9969: panic in T7562 In-Reply-To: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> References: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> Message-ID: <061.6304044f5c32d5ee50ffe2bb4b5b682e@haskell.org> #9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T7562 Blocked By: | Blocking: Related Tickets: #7562 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Merged to 7.10 in commit ccb7d96da42663407f1cd73355821ca5a7f55e7f: {{{ Author: Simon Peyton Jones Date: Fri Jan 9 09:46:37 2015 +0000 Return a [HsImplBang] from dataConImplBangs even with NoDataConRep This fixes Trac #9969, a new crash in T7562 that I somehow missed when fiddling with HsBang (cherry picked from commit 327ce1d336c8fbdb068be900a187f96d1c60b851) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:00:56 -0000 Subject: [GHC] Batch modify: #10186, #10139, #9554, #10140, #10132, #10112, ... Message-ID: <20160107140056.8F8343A2FF@ghc.haskell.org> Batch modification to #10186, #10139, #9554, #10140, #10132, #10112, #10026, #10040, #9973, #9972, #9939 by thomie: milestone to 8.0.1 Action: leave -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:10:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:10:43 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.052e83b6b32b505fbfc81c8240a0b2d4@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): I wonder if some kind of pragma would make more sense than trying to come up with a clever heuristic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:11:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:11:28 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.7497a3a5bccd7f8888d4c37e8d456e81@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I?m not sure if the 3-release-policy should get in the way of useful compilier output, and `-Wall` is (rightfully) used by developers to ask the compiler to comment the code as much as sensibly possible. We could refine the policy to promise (or thrive) to deliver `-Wall -Wno- redundant-constraints` cleanliness, and similarly disable other warnings that get in the way of a nice backward-facing compatibility story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:17:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:17:12 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions Message-ID: <046.772da5831321f90972ab679b44e7eb97@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Bartosz [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010892.html reports] that substitution isn't working properly for him. He cites this Note in `TyCoRep`: {{{ -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x)) -- Urk! This means looking at all the calls to mkOpenTCvSubst.... }}} I think this is an outright bug that has been lurking for ages, and which Bartosz has just managed to tickle. Things to do: * We should add an ASSERT to substTy (and similar functions): **when calling `substTy subst ty` it should be the case that the in-scope set in the substitution is a superset of** * **The free vars of the range of the substitution** * **The free vars of ty minus the domain of the substitution** That ASSERT could be added to the immediate callers of `subst_ty` in `TyCoRep`. (Bartosz: if you add that you should find that it trips before the bug you are actually getting.) * How to fix it properly? The places to look are: everywhere that uses (transitively) one of the `mkOpenTCvSubst` or `zipOpenTCvSubst` functions. * Many calls to `mkOpenTCvSubst` produce a substitution that is only applied to closed types; or at least to types whose only free variables are the ones in the domain of the substitution. Example: the call to `zipOpenTCvSubst` in `DataCon.dataConInstSig`. These ones will all satisfy the ASSERT[[BR]][[BR]] * In other cases, we already have the in-scope set in hand. Example: in `CoreLint.lintTyApp` we find a call to `substTyWith`. But Lint carries an in-scope set, so it would be easy to pass it to `substTyWith`.[[BR]][[BR]] * Finally there may be cases where we really have to take the free vars of the type we are substituting into, and add them to the in-scope set. Doubtless all this applies to substituting in coercions too, and indeed into expressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:18:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:18:54 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.bd793172fa7d6fa804275a553b3d3495@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 simonpj): Do you have an idea of what's going on here Bartosz? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:25:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:25:08 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.dc5b75b25aa66f4a079b54ddc1f0b05b@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed, a pragma would be good. If someone is going to add class-specific pragmas, making `UndecidableSuperClasses` work on a per-class (rather than per-module) basis would be good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:30:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:30:29 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.788ab3ee2eb7ae072923deb097433f79@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): From a GHC point of view, I think we can do whatever the Core Libraries Committee wants. Eg. switch off `-Wno-redundant-constraints` for 8.0 and switch it on for 8.2. Or whatever. But I have always felt uncomfortable with the way that warnings are being essentially treated like errors: you must not have any. After all, if we switch it off, the exact same issue will arise the moment we switch it on! Maybe we need three categories: * **Errors**: we can't compile your program * **Warnings**: we can compile it but your library should probably be warning-free * **Advisories**: there's something fishy, but no expectation that a library will be advisory-free. However advisories may become warnings in the next release, so you may want to invest a bit of effort at your convenience in getting rid of them. I see our users (embodied in the Core Libraries Committee) as being in the driving seat here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:48:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:48:09 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.8fb1df3f6364a9b613c44f99074e1ee9@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: highest => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 14:53:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 14:53:57 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.c72e0cffcb802b6fdbbe22a38a33567f@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Demoting priority since there is an obvious workaround here: disable the warning in the module that defines `unthrow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:06:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:06:46 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.8c04bcaed9a009ccf57aa434836bac41@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: quchen (added) Comment: NB: Currently `-Wredundant-constraints` is part of the default warning set (i.e. it's active even w/o `-W` or `-Wall`) (also, a tentative plan for GHC 8.2 is to overhaul the warning system to support warning-sets more uniformly, see also Design/Warnings) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:15:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:15:23 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.37b5657450618c2fffbeb4b65fe2b43f@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:15:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:15:54 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.e336bb46c9988079c94f0bf74a280bc3@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 niteria): I believe the problem is here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/typecheck/TcTyClsDecls.hs;c78fedde7055490ca6f6210ada797190f3c35d87$1003 There's no reason to believe that `ktvs` and `mkTyVarTys fam_tc_tvs` will be in the matching order, and indeed `ktvs` is in the order of uniques. We start out with: {{{ type Fam a_a18o3H b_a18o3G :: * type Fam a_a18o3F x_a18o3E = FamHelper a_a18o3F x_a18o3E }}} then when we reach `tcDefaultAssocDecl` we have: `FamHelper (a_a18o3F |> <*>_N) (x_a18o3E |> <*>_N) |> <*>_N)` `ktvs` is `[x_a18o3E, a_a18o3F]` `mkTyVarTys fam_tc_tvs` is `[a_a18o3H, b_a18o3G]` When we zip them together we end up with a definition that flips the arguments. From there it goes downhill, because when we try to compute `Fam Int Bool` we do it with flipped arguments: `FamHelper Bool Int` which is `(String, Bool)` which eventually doesn't unify with `Maybe Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:16:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:16:13 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.1164bb409c5966a2ad2a58beffbe3bce@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): Replying to [comment:8 simonpj]: > Well in normal code you can't write > {{{ > f :: Int -> Int > }}} > and omit the declaration of `f`. You have to write > {{{ > f :: Int -> Int > f = undefined > }}} > So it's consistent to require the same for pattern synonyms. Funny you bring that up! I'm not sure if it's by design or a regression but omitting a method declaration (GHC 7.10) used to give a warning: {{{ Prelude> :set -XInstanceSigs Prelude> class A a where f :: a Prelude> instance A Int where f :: Int :11:10: Warning: No explicit implementation for ?f? In the instance declaration for ?A Int? }}} while in 8.1: {{{ :3:22: error: The class method signature for ?f? lacks an accompanying binding (The class method signature must be given where ?f? is declared) }}} which [https://xkcd.com/1172/ affects me similarly]: I usually turn off warnings while churning out code and turn them on afterwards, now one must write a dummy definition "f = undefined" (maybe it's not so silly to expand standalone type signatures ?top-level, where block, instance? into a dummy declaration: `-fcut-me-some-slack`....)? > For my money, I think it's maybe a mistake for the unidirectional/bidirectional split to be so quietly signaled. One could imagine > {{{ > pattern unidirectional Q a = pat > pattern bidirectional P a b = pat > pattern bidirectional R x = pat where R = ... > }}} > But opinions vary. May be! I feel it plays into the usual duality between reading and writing code. Your suggestion would certainly be clearer to people unfamiliar with pattern synonyms and all the different variations thereof, make it easier to search for and `grep` code. Consider my [comment:5 response to mpickering] as an offhand remark ? a data point. It certainly should not dictate any design decisions. > Usually `where` clauses contain zero or more bindings, which is why an empty `where` is usually ok. But here it must contain exactly one. (Two would not make sense either.) Could you not view a `where` clause in a pattern synonym as containing zero bindings (unidirectional) or a single binding (explicitly bidirectional). ? The more I think about it the less objectionable it sounds, as a flag solely for development. It's common to write stubs in Haskell given only their type with an dummy definition to satisfy the compiler, the compiler could expand `getId :: Person -> Id` into {{{#!hs getId :: Person -> Id getId = error "getId:15:1: Not defined." }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:16:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:16:38 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could Message-ID: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, | Operating System: Unknown/Multiple loopification, code generation | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The loopification optimization, as I understand it, allows a self- recursive function to jump to a local label instead of the beginning of the function, thus skipping a potential stack check. However, I only observe it triggering for pure functions while IO functions do not get that benefit, even when it would be possible. I discovered this in #8793 after looking into an unexpected speedup by removing the IO context from an otherwise pure loop and while such a loop can simply be changed to a pure version (the {{{IOLoop}}} examples), other functions can not, but the optimization could be applied to them (see {{{MapM.hs}}}). I tried to benchmark the differences between a naive loop in IO and some horrible {{{inlinePerformIO}}} hacks to get the loopification to fire and the "optimized" version performs 3-5% faster on my machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:16:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:16:50 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.dad6500b30360cb4a1aa4f79f9d2b0e3@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): All this scares me a lot. Why does the package database need to record the versioned .so dependency? It is not required, either for linking against the dynamic library (because it is already recorded as a dependency in the .so) or against the static library (because we use -lfoo). We require the `-dev` versions of libraries for GHCi very deliberately, because GHCi is supposed to mimic the linking that would be done for a standalone executable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:18:51 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.7accab1418bc40ffacde1ae7bf5717a7@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation 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 jscholl): * Attachment "MapM.hs" added. mapM_ implementation as example of a loop which would benefit from the optimization, but currently doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:19:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:19:37 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.65ff572db5f95ebe1f0e1ef418e16690@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Comment (by simonmar): > Unload (dlclose) the dummy shared object. This will also unload shared objects that are to be unloaded (unless they are still referenced by other still loaded libraries). Note that (as discussed in D1631) this is dangerous because there might still be references to the old code from the heap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:20:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:20:07 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.87885d023405ee0bf0251affc331b67d@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation 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 jscholl): * Attachment "IOLoop.hs" added. Loop which can be made pure by the user -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:20:11 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.e525df97a1e97b01f8b6dfc8888c4366@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * related: => #11360 Comment: I believe #11360 is one symptom of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:24:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:24:01 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.4f82923d599e33d131c526d6c3871e95@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 mpickering): I think this reply is a mixture of a new ticket, #393 and some more context for this ticket. > Could you not view a where clause in a pattern synonym as containing zero bindings (unidirectional) or a single binding (explicitly bidirectional). Yes you could, without looking I think this would require quite a bit of refactoring because of how everything is dealt with in the parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:28:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:28:37 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.4dad6553ee8848df7166713bb68352ce@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:29:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:29:04 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.270c9e923789beb8fae1d7f3e0476d25@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Phab:D1742 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * differential: => Phab:D1742 Comment: I opened #11372 for the loopification issue. And added the differential to this ticket (which I think I should have done earlier, but somehow I thought this would be done automatically if I mention this ticket on phabricator). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:48:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:48:12 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.cc26cc45b5a8eee3015df1f98a63a27e@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation 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 simonpj: Old description: > The loopification optimization, as I understand it, allows a self- > recursive function to jump to a local label instead of the beginning of > the function, thus skipping a potential stack check. However, I only > observe it triggering for pure functions while IO functions do not get > that benefit, even when it would be possible. > > I discovered this in #8793 after looking into an unexpected speedup by > removing the IO context from an otherwise pure loop and while such a loop > can simply be changed to a pure version (the {{{IOLoop}}} examples), > other functions can not, but the optimization could be applied to them > (see {{{MapM.hs}}}). > > I tried to benchmark the differences between a naive loop in IO and some > horrible {{{inlinePerformIO}}} hacks to get the loopification to fire and > the "optimized" version performs 3-5% faster on my machine. New description: The loopification optimization, as I understand it, allows a self- recursive function to jump to a local label instead of the beginning of the function, thus skipping a potential stack check. However, I only observe it triggering for pure functions while IO functions do not get that benefit, even when it would be possible. I discovered this in #8793 after looking into an unexpected speedup by removing the IO context from an otherwise pure loop and while such a loop can simply be changed to a pure version (the {{{IOLoop}}} examples), other functions can not, but the optimization could be applied to them (see {{{MapM.hs}}}). I tried to benchmark the differences between a naive loop in IO and some horrible {{{inlinePerformIO}}} hacks to get the loopification to fire and the "optimized" version performs 3-5% faster on my machine. See [wiki:Commentary/Compiler/Loopification] for details -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:50:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:50:58 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.f354159a21184c003dfbcc29922a8486@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): Replying to [comment:10 mpickering]: > I think this reply is a mixture of a new ticket, #393 and some more context for this ticket. Thanks mpickering, #393 looks promising. I have a keyboard macro for inserting `"undefined "`, if it got implemented I would use it aggressively: {{{ >>> data X >>> data Y >>> f :: X ? Y >>> :t map f map f :: [X] -> [Y] }}} looks great. Could [[ExplicitCallStack/ImplicitLocations]] be an alternative in #393 to `-fdefer-type-errors` + typed holes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:56:14 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.f78972b5c3bd16cc162165b87c4ab968@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): Replying to [comment:10 mpickering]: > > Could you not view a where clause in a pattern synonym as containing zero bindings (unidirectional) or a single binding (explicitly bidirectional). > > Yes you could, without looking I think this would require quite a bit of refactoring because of how everything is dealt with in the parser. If we take the route of #393 a pattern synonym `where` could always indicate an explicitly bidirectional pattern with a single clause: {{{#!hs pattern A <- 'a' where ---expands-into--> pattern A <- 'a' where A = _ }}} to Simon's point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 15:56:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 15:56:46 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.63993f90dcd4c50c4e6fe390276e7ce9@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I'll move the discussion to Phab so that we can make comments on particular pieces of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 16:01:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 16:01:02 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.99036367fe7b94704ad732aa16da4ef3@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #393 #5791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 16:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 16:13:30 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.73ff6a72201c46b2fa3f389a4d2878f4@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D1407 => Phab:D1407, Phab:D1595, Phab:D1747 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 16:14:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 16:14:32 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.f3dd02e3c77d11b28e3aaafb97c29a1d@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D1562 => Phab:D1562,Phab:D1747,Phab:D1748 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 16:21:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 16:21:48 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.36cef982385fd57e418d5cb3939038a3@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): From a CLC perspective, I'd consider anything involving unboxed string literals to fall under the purview of the GHC developers. It is a very compiler-specific detail that doesn't leak into much user visible code, so whatever you think is cleanest should be good enough for us. As for the lack of an operation for `String# -> Addr#` that gets a bit messier. We already have {{{#!hs byteArrayContents# :: ByteArray# -> Addr# }}} replete with the caveat that it should only be used with pinned byte arrays and with the suggestion that `String# = ByteArray#` these are effectively pre-pinned byte array literals. The existence of that primitive wasn't an issue until now, but becomes one in the presence of unboxed string literals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 16:37:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 16:37:41 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.b33068b09587dbbce79781f53b2069f0@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.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 ezyang): So, in some sense, you are actually completely screwed, because at runtime the executable producing Tix files has no idea if it was compiled from `Main1.hs` or `Main2.hs`: the symbol names for the two executables live in the same namespace, etc. There is actually a very cunning way this problem could be fixed: 1. `-main-is` could be extended to work with modules which are not in the `main` package. 2. Executables could then be compiled while setting `-package-name` to something that is not `main`. Then the symbol names would be different and you could merge them reliably. The alternative is that HPC can be told explicitly that a mix file is for a specific file name (extending it's model to not be profiling a pile of `Module`s, but a pile of `Module`s or files). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 16:47:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 16:47:01 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.198bf45a74611fa5423983f54562d75c@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Comment (by simonmar): On Linux this test triggers the `stg_exit(EXIT_HEAPOVERFLOW)` here: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/sm/MBlock.c;c78fedde7055490ca6f6210ada797190f3c35d87$202 It repeatedly allocates 2GB arrays and eventually runs out of the 1TB address space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 19:46:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 19:46:21 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.6a7d8bfb40c758f1db75c7a15ad23bfc@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by thomie): Related Cabal ticket: https://github.com/haskell/cabal/issues/2982. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 20:05:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 20:05:53 -0000 Subject: [GHC] #11373: GHC should support static archive creation on all systems Message-ID: <045.405e05abe0dd276b4e28f13c03cde02f@haskell.org> #11373: GHC should support static archive creation on all systems -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.11 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 in `DriverPipeline.hs`: {{{ linkStaticLibCheck :: DynFlags -> [String] -> [UnitId] -> IO () linkStaticLibCheck dflags o_files dep_packages = do when (platformOS (targetPlatform dflags) `notElem` [OSiOS, OSDarwin]) $ throwGhcExceptionIO (ProgramError "Static archive creation only supported on Darwin/OS X/iOS") linkBinary' True dflags o_files dep_packages }}} Seems a bit odd/awful for this to only work on OS X. Either we should support none of it (not GHC's job) or all of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 20:10:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 20:10:43 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup Message-ID: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm afraid I've found yet another case that still let's the pattern checker go crazy (courtesy of hackage:cryptol-2.2.5): {{{#!hs {-# LANGUAGE Haskell2010 #-} {-# OPTIONS_GHC -Woverlapping-patterns #-} module Bug where data Type = TCon TCon [Type] | TUser String [Type] Type | TRec [(String,Type)] deriving (Show,Eq,Ord) data TCon = TC TC | TF TFun deriving (Show,Eq,Ord) data TC = TCNum Integer | TCInf | TCBit | TCSeq | TCFun | TCTuple Int deriving (Show,Eq,Ord) data TFun = TCAdd | TCSub | TCMul | TCDiv | TCMod | TCLg2 | TCExp | TCWidth | TCMin | TCMax | TCLenFromThen | TCLenFromThenTo deriving (Show, Eq, Ord, Bounded, Enum) simpFinTy :: Type -> Maybe [Type] simpFinTy ty = case ty of TCon (TC (TCNum _)) _ -> Just [] TCon (TF tf) [t1] | TCLg2 <- tf -> Just [t1] | TCWidth <- tf -> Just [t1] TCon (TF tf) [t1,t2] | TCAdd <- tf -> Just [t1, t2] | TCSub <- tf -> Just [t1] | TCMul <- tf -> Just [t1, t2] | TCDiv <- tf -> Just [t1] | TCMod <- tf -> Just [] | TCExp <- tf -> Just [t1, t2] | TCMin <- tf -> Nothing | TCMax <- tf -> Just [t1, t2] TCon (TF tf) [_,_,_] | TCLenFromThen <- tf -> Just [] | TCLenFromThenTo <- tf -> Just [] _ -> Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 20:26:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 20:26:14 -0000 Subject: [GHC] #11373: GHC should support static archive creation on all systems In-Reply-To: <045.405e05abe0dd276b4e28f13c03cde02f@haskell.org> References: <045.405e05abe0dd276b4e28f13c03cde02f@haskell.org> Message-ID: <060.cff80e296dd8ac6c2e36a5e05556a756@haskell.org> #11373: GHC should support static archive creation on all systems -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Driver | Version: 7.11 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 thomie): * component: Compiler => Driver Comment: That code was added in #8127, commit 98b0d05de35bd531102d832f3108050549fd781f: {{{ Author: Austin Seipp Date: Wed Aug 28 16:55:42 2013 -0500 Rework how iOS does linking (#8127) iOS has some particular constraints about how applications can be built: * We must generate a static library (.a) since XCode does the final link. * We need to carefully give the right set of arguments to libtool in the case we're generating an archive. * Dynamic linking isn't supported. * It can only be done on OS X. This patch cleans up all of the above. We add a new flag `-staticlib` (only supported on Darwin) that allows us to produce archive files using libtool, and a -pgmlibtool flag to control which 'libtool' executable to use. This fixes #8127. I believe this is the last piece missing from the iOS cross compiler. Authored-by: Luke Iannini Authored-by: Maxwell Swadling Authored-by: Stephen Blackheath <... at blacksapphire.com> Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 20:58:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 20:58:57 -0000 Subject: [GHC] #9724: reexport IsList class from a trustworthy module In-Reply-To: <044.b4b824d4864a7071bef003961687614b@haskell.org> References: <044.b4b824d4864a7071bef003961687614b@haskell.org> Message-ID: <059.72bf77c150b5ca36e9fda76605246bda@haskell.org> #9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: SafeHaskell 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 thomie): * cc: dterei, ekmett (added) * keywords: => SafeHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 21:57:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 21:57:10 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. Message-ID: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: aarch64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! This bug is awkard at last to me. So I notiiced today, that using type aliases in my code takes twice as long to copile than using closed type families with just single member. So to be most precise - when I replace the following line: {{{ type XQ1 m a = Targets (Match m a) }}} with {{{ type family XQ1 m a where XQ1 m a = Targets (Match m a) }}} the compilation time drops from 15s to 7s (this type alias is heavily used across the application). I think it could be somehow related to the famous #8095 bug, but I can of course be wrong here. Unfortunetally the codebase is pretty big and its not so easy to make a minimal example, but I'll try to work on it during the upcoming weekend (please notify me if that would not be necessary). And some statistics from `-dshow-passes`: When using type alias: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 66,949, coercions: 16,383,834} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,391, coercions: 16,507,338} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,437, coercions: 16,504,770} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,347, coercions: 16,504,734} Result size of Simplifier = {terms: 10,543, types: 74,347, coercions: 16,504,630} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,522, coercions: 16,504,729} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,430, coercions: 16,504,729} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} and with type families: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 310, types: 867, coercions: 78} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 301, types: 878, coercions: 296} Result size of Simplifier = {terms: 301, types: 878, coercions: 293} *** Tidy Core: Result size of Tidy Core = {terms: 337, types: 1,002, coercions: 293} *** CorePrep: Result size of CorePrep = {terms: 475, types: 1,305, coercions: 293} *** ByteCodeGen: *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_93.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_92.o compile: input file /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_1.hscpp *** Checking old interface for Main: [45 of 45] Compiling Main ( /Users/wdanilo/dev/hs/public/variants/Main.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 67,609, coercions: 162,249} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,721, coercions: 323,027} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,767, coercions: 320,473} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,677, coercions: 320,437} Result size of Simplifier = {terms: 10,543, types: 74,677, coercions: 320,333} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,852, coercions: 320,432} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,760, coercions: 320,432} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} As we can see the type aliases produce much more coertions: 16,383,834 vs 78 using type families. This is really interesting thing and it seems related to the linked bug above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 21:59:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 21:59:36 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.ad4030bf5edca16c5731f9fac79b7fe6@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello guys! This bug is awkard at last to me. So I notiiced today, that > using type aliases in my code takes twice as long to copile than using > closed type families with just single member. So to be most precise - > when I replace the following line: > {{{ > type XQ1 m a = Targets (Match m a) > }}} > > with > > {{{ > type family XQ1 m a where XQ1 m a = Targets (Match m a) > }}} > > the compilation time drops from 15s to 7s (this type alias is heavily > used across the application). I think it could be somehow related to the > famous #8095 bug, but I can of course be wrong here. > > Unfortunetally the codebase is pretty big and its not so easy to make a > minimal example, but I'll try to work on it during the upcoming weekend > (please notify me if that would not be necessary). > > And some statistics from `-dshow-passes`: > > When using type alias: > {{{ > *** Parser: > *** Renamer/typechecker: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 10,303, types: 66,949, coercions: 16,383,834} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 10,722, types: 75,391, coercions: 16,507,338} > Result size of Simplifier iteration=2 > = {terms: 10,550, types: 74,437, coercions: 16,504,770} > Result size of Simplifier iteration=3 > = {terms: 10,543, types: 74,347, coercions: 16,504,734} > Result size of Simplifier > = {terms: 10,543, types: 74,347, coercions: 16,504,630} > *** Tidy Core: > Result size of Tidy Core > = {terms: 10,846, types: 75,522, coercions: 16,504,729} > *** CorePrep: > Result size of CorePrep > = {terms: 14,823, types: 96,430, coercions: 16,504,729} > *** ByteCodeGen: > Upsweep completely successful. > *** Deleting temp files: > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o > Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, > Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, > Control.Monad.State.Dependent, Control.Monad.Poly, > Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, > Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, > Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, > Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, > Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, > Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, > Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, > Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, > Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, > Data.Convert.Instances, Data.Convert.Instances.Map, > Data.Convert.Instances.Num, Data.Convert.Instances.Text, > Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. > *** Parser: > *** Desugar: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > ... > }}} > > and with type families: > > {{{ > *** Parser: > *** Renamer/typechecker: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 310, types: 867, coercions: 78} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 301, types: 878, coercions: 296} > Result size of Simplifier > = {terms: 301, types: 878, coercions: 293} > *** Tidy Core: > Result size of Tidy Core > = {terms: 337, types: 1,002, coercions: 293} > *** CorePrep: > Result size of CorePrep > = {terms: 475, types: 1,305, coercions: 293} > *** ByteCodeGen: > *** Deleting temp files: > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_93.c > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_92.o > compile: input file > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_1.hscpp > *** Checking old interface for Main: > [45 of 45] Compiling Main ( > /Users/wdanilo/dev/hs/public/variants/Main.hs, interpreted ) > *** Parser: > *** Renamer/typechecker: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 10,303, types: 67,609, coercions: 162,249} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 10,722, types: 75,721, coercions: 323,027} > Result size of Simplifier iteration=2 > = {terms: 10,550, types: 74,767, coercions: 320,473} > Result size of Simplifier iteration=3 > = {terms: 10,543, types: 74,677, coercions: 320,437} > Result size of Simplifier > = {terms: 10,543, types: 74,677, coercions: 320,333} > *** Tidy Core: > Result size of Tidy Core > = {terms: 10,846, types: 75,852, coercions: 320,432} > *** CorePrep: > Result size of CorePrep > = {terms: 14,823, types: 96,760, coercions: 320,432} > *** ByteCodeGen: > Upsweep completely successful. > *** Deleting temp files: > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o > Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, > Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, > Control.Monad.State.Dependent, Control.Monad.Poly, > Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, > Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, > Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, > Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, > Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, > Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, > Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, > Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, > Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, > Data.Convert.Instances, Data.Convert.Instances.Map, > Data.Convert.Instances.Num, Data.Convert.Instances.Text, > Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. > *** Parser: > *** Desugar: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > ... > }}} > > As we can see the type aliases produce much more coertions: 16,383,834 vs > 78 using type families. This is really interesting thing and it seems > related to the linked bug above. New description: Hello guys! This bug is awkard at last to me. So I notiiced today, that using type aliases in my code takes twice as long to copile than using closed type families with just single member. So to be most precise - when I replace the following line: {{{ type XQ1 m a = Targets (Match m a) }}} with {{{ type family XQ1 m a where XQ1 m a = Targets (Match m a) }}} the compilation time drops from 15s to 7s (this type alias is heavily used across the application). I think it could be somehow related to the famous #8095 bug, but I can of course be wrong here. Unfortunetally the codebase is pretty big and its not so easy to make a minimal example, but I'll try to work on it during the upcoming weekend (please notify me if that would not be necessary). And some statistics from `-dshow-passes`: When using type alias: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 66,949, coercions: 16,383,834} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,391, coercions: 16,507,338} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,437, coercions: 16,504,770} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,347, coercions: 16,504,734} Result size of Simplifier = {terms: 10,543, types: 74,347, coercions: 16,504,630} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,522, coercions: 16,504,729} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,430, coercions: 16,504,729} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} and with type families: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 67,609, coercions: 162,249} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,721, coercions: 323,027} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,767, coercions: 320,473} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,677, coercions: 320,437} Result size of Simplifier = {terms: 10,543, types: 74,677, coercions: 320,333} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,852, coercions: 320,432} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,760, coercions: 320,432} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} As we can see the type aliases produce much more coertions: 16,383,834 vs 162,249 using type families. This is really interesting thing and it seems related to the linked bug above. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 22:01:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 22:01:05 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.6c17e29aea837c3722353168619c2539@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hello guys! This bug is awkard at last to me. So I notiiced today, that > using type aliases in my code takes twice as long to copile than using > closed type families with just single member. So to be most precise - > when I replace the following line: > {{{ > type XQ1 m a = Targets (Match m a) > }}} > > with > > {{{ > type family XQ1 m a where XQ1 m a = Targets (Match m a) > }}} > > the compilation time drops from 15s to 7s (this type alias is heavily > used across the application). I think it could be somehow related to the > famous #8095 bug, but I can of course be wrong here. > > Unfortunetally the codebase is pretty big and its not so easy to make a > minimal example, but I'll try to work on it during the upcoming weekend > (please notify me if that would not be necessary). > > And some statistics from `-dshow-passes`: > > When using type alias: > {{{ > *** Parser: > *** Renamer/typechecker: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 10,303, types: 66,949, coercions: 16,383,834} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 10,722, types: 75,391, coercions: 16,507,338} > Result size of Simplifier iteration=2 > = {terms: 10,550, types: 74,437, coercions: 16,504,770} > Result size of Simplifier iteration=3 > = {terms: 10,543, types: 74,347, coercions: 16,504,734} > Result size of Simplifier > = {terms: 10,543, types: 74,347, coercions: 16,504,630} > *** Tidy Core: > Result size of Tidy Core > = {terms: 10,846, types: 75,522, coercions: 16,504,729} > *** CorePrep: > Result size of CorePrep > = {terms: 14,823, types: 96,430, coercions: 16,504,729} > *** ByteCodeGen: > Upsweep completely successful. > *** Deleting temp files: > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o > Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, > Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, > Control.Monad.State.Dependent, Control.Monad.Poly, > Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, > Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, > Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, > Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, > Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, > Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, > Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, > Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, > Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, > Data.Convert.Instances, Data.Convert.Instances.Map, > Data.Convert.Instances.Num, Data.Convert.Instances.Text, > Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. > *** Parser: > *** Desugar: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > ... > }}} > > and with type families: > > {{{ > *** Parser: > *** Renamer/typechecker: > *** Desugar: > Result size of Desugar (after optimization) > = {terms: 10,303, types: 67,609, coercions: 162,249} > *** Simplifier: > Result size of Simplifier iteration=1 > = {terms: 10,722, types: 75,721, coercions: 323,027} > Result size of Simplifier iteration=2 > = {terms: 10,550, types: 74,767, coercions: 320,473} > Result size of Simplifier iteration=3 > = {terms: 10,543, types: 74,677, coercions: 320,437} > Result size of Simplifier > = {terms: 10,543, types: 74,677, coercions: 320,333} > *** Tidy Core: > Result size of Tidy Core > = {terms: 10,846, types: 75,852, coercions: 320,432} > *** CorePrep: > Result size of CorePrep > = {terms: 14,823, types: 96,760, coercions: 320,432} > *** ByteCodeGen: > Upsweep completely successful. > *** Deleting temp files: > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c > Warning: deleting non-existent > /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o > Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, > Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, > Control.Monad.State.Dependent, Control.Monad.Poly, > Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, > Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, > Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, > Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, > Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, > Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, > Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, > Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, > Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, > Data.Convert.Instances, Data.Convert.Instances.Map, > Data.Convert.Instances.Num, Data.Convert.Instances.Text, > Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. > *** Parser: > *** Desugar: > *** Simplify: > *** CorePrep: > *** ByteCodeGen: > ... > }}} > > As we can see the type aliases produce much more coertions: 16,383,834 vs > 162,249 using type families. This is really interesting thing and it > seems related to the linked bug above. New description: Hello guys! This bug is awkard at last to me. So I notiiced today, that using type aliases in my code takes twice as long to copile than using closed type families with just single member. So to be most precise - when I replace the following line: {{{ type XQ1 m a = Targets (Match m a) }}} with {{{ type family XQ1 m a where XQ1 m a = Targets (Match m a) }}} the compilation time drops from 15s to 7s (this type alias is heavily used across the application). I think it could be somehow related to the famous #8095 bug, but I can of course be wrong here. Unfortunetally the codebase is pretty big and its not so easy to make a minimal example, but I'll try to work on it during the upcoming weekend (please notify me if that would not be necessary). And some statistics from `-dshow-passes`: When using type alias: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 66,949, coercions: 16,383,834} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,391, coercions: 16,507,338} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,437, coercions: 16,504,770} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,347, coercions: 16,504,734} Result size of Simplifier = {terms: 10,543, types: 74,347, coercions: 16,504,630} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,522, coercions: 16,504,729} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,430, coercions: 16,504,729} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} and with type families: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 67,609, coercions: 162,249} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,721, coercions: 323,027} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,767, coercions: 320,473} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,677, coercions: 320,437} Result size of Simplifier = {terms: 10,543, types: 74,677, coercions: 320,333} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,852, coercions: 320,432} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,760, coercions: 320,432} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} As we can see the type aliase (used in one single place (!)) produces (100 x) more coertions than type families: `16,383,834` vs `162,249`. This is really interesting thing and it seems related to the linked bug above. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 22:27:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 22:27:52 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.249a22044da427be7970ad6bb4baa267@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is mysterious. I have absolutely no idea what is happening. So a way to reproduce would indeed be useful! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 7 23:22:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jan 2016 23:22:42 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.579f9406e30acdcebe29ed143cdaeed7@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T11341 Blocked By: | Blocking: Related Tickets: #10828 | Differential Rev(s): Phab:D1738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 8.1 => 7.11 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 00:01:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 00:01:07 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications Message-ID: <050.1e1b033722e186882d08840a201168c5@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010915.html here]. When applying types via `-XTypeApplications`, the type/kind that gets instantiated seems to be different depending on whether you're using functions, datatypes, or typeclasses. Here's an example contrasting functions and datatypes: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType ?> data Prox a = Prox ?> prox :: Prox a; prox = Prox ?> :t prox prox :: forall k (a :: k). Prox k a ?> :t prox @Int prox @Int :: Prox * Int ?> :t Prox Prox :: forall k (a :: k). Prox k a ?> :t Prox @Int Prox @Int :: Prox Int a }}} This is the core of the problem: with a function, `Int` seems to be applied to type variable `a`, whereas with data types, `Int` appears to be applied to the kind variable `k`. This confuses me, since `k` wasn't specified anywhere in the definition of `Prox`. Andres L?h also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010916.html observed] a similar discrepancy between functions and typeclasses: {{{ ?> :set -XScopedTypeVariables ?> class C a where c :: () ?> d :: forall a. C a => (); d = c @_ @a ?> :t d d :: forall k (a :: k). C k a => () ?> :t d @Int d @Int :: C * Int => () ?> :t c c :: forall k (a :: k). C k a => () ?> :t c @Int c @Int :: C Int a => () ?> :t c @_ @Int c @_ @Int :: C * Int => () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 00:08:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 00:08:25 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.848034ad2a8bc2ca322f7bc32b5119e4@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This ''might'' also affect data families too, but maybe not, since you have to specify the kind in the data family declaration: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -fprint-explicit-kinds -XTypeInType -XTypeApplications -XTypeFamilies ?> data family Fam (a :: k) ?> data instance Fam a = FamCon ?> famCon :: Fam a; famCon = FamCon ?> :t famCon famCon :: forall k (a :: k). Fam k a ?> :t famCon @Int famCon @Int :: Fam * Int ?> :t FamCon FamCon :: forall k (a :: k). Fam k a ?> :t FamCon @Int FamCon @Int :: Fam Int a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 00:08:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 00:08:55 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.e06084b98c87c41be53d6b5998950736@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm confused even earlier: why are `Prox` and `prox` polykinded at all? Does one of `TypeApplications` or `TypeInType` imply `PolyKinds`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 00:12:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 00:12:04 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.a8abb9e2cd522fc215dc7382aef23c25@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `-XTypeInType` switches on a menagerie of extensions, including `-XPolyKinds`: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeInType ?> :showi language base language is: Haskell2010 with the following modifiers: -XDataKinds -XNoDatatypeContexts -XExtendedDefaultRules -XKindSignatures -XNoMonomorphismRestriction -XNondecreasingIndentation -XPolyKinds -XTypeInType }}} `-XTypeApplications` enables some others, too: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeApplications ?> :showi language base language is: Haskell2010 with the following modifiers: -XAllowAmbiguousTypes -XNoDatatypeContexts -XExtendedDefaultRules -XNoMonomorphismRestriction -XNondecreasingIndentation -XTypeApplications }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 00:19:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 00:19:11 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.58e6b06d45119149a8273cbf473840ab@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So `TypeInType` enables `DataKinds` and `PolyKinds`, and `TypeApplications` enables `AllowAmbiguousTypes`. (The rest are default in ghci.) Turning off the "kind defaulting" to * from standard Haskell could result in some pretty confusing errors! Think of situations like #11324. But, OK, I guess... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 01:09:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 01:09:01 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.2857bb0016f86f7ac57a8df916db0b62@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): > Yes, exactly. That is much simpler than "meta-nodes", and had the great merit of being correct (see third bullet). Agreed. My graph approach was all wrong, so I've ditched it. I think it would be ideal if we didn't have to plumb the `FreeVars` past `rnSrcDecls` and onto `tcTyAndClassDecls`, so I've come up with a solution which does essentially what you've described but during dependency analysis. 1. Compute the SCCs for `TyClDecl`s as we do now in HEAD. 2. For all of the `InstDecl`s (I includes class and data family instances. Any harm in doing so?), associate it with its `FreeVars`, intersected with the set of `Name`s of `TyClDecl`s that we just analysed. 3. Fold the list of SCCs, at each step extracting the set of `InstDecl`s for which its `FreeVars` is empty, and then eliminating all of the `Name`s found in that SCC. That set of `InstDecl`s, if non-empty, comes before the current component in the output list. Will upload the patch in a few seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 01:09:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 01:09:20 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.74ceea6439430ecacd72ce6b11e55951@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): * Attachment "0002-Fix-11348-handle-instance-dependencies.2.patch" added. Fix candidate 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 03:32:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 03:32:26 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.51204984f22f44fa76ad34e65625adea@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications 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 goldfire): * owner: => goldfire * keywords: TypeInType => TypeApplications Comment: Yes, to comment:4. And there does seem to be a discrepancy between the handling of kinds in datatype/class declarations and functions. I have a guess as to why. I'll look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 05:02:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 05:02:28 -0000 Subject: [GHC] #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules In-Reply-To: <044.730164fd4456e5107de56b5da1c9dd5d@haskell.org> References: <044.730164fd4456e5107de56b5da1c9dd5d@haskell.org> Message-ID: <059.f72aeccb123dcb242fbb20378605c4cd@haskell.org> #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules -------------------------------------+------------------------------------- Reporter: tvynr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: This is a Cabal bug: https://github.com/haskell/cabal/issues/2982 Later reported duplicate: https://ghc.haskell.org/trac/ghc/ticket/9009 GHC is not really in the business of checking the well-formedness of archive files installed in the package database, so there is not much GHC can do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 05:03:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 05:03:08 -0000 Subject: [GHC] #9009: Confusing error message when loading package with TH In-Reply-To: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> References: <048.9876a56e7deff864166fd8db42e13f9c@haskell.org> Message-ID: <063.7fc9446d8fd88fc20e8623800cc4c80c@haskell.org> #9009: Confusing error message when loading package with TH -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 8060 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: => 8060 Comment: Duplicate of #8060. By the way, GHC is not really in the business of checking the well- formedness of archive files installed in the package database, so there is not much GHC can do here. Cabal needs to fix the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 05:11:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 05:11:18 -0000 Subject: [GHC] #7277: Recompilation check fails for TH unless functions are inlined In-Reply-To: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> References: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> Message-ID: <065.0f018049ffe1436dcd6d1ed1d0edc273@haskell.org> #7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: orenbenkiki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Related #7414, which is the opposite problem but for plugins: we ALWAYS recompile, even when the implementation is the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 05:11:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 05:11:42 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.4c5ab5cd70f3bae8e8a697f03a850817@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | recompilation 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 ezyang): Related #7277, which has the opposite problem where rely only on the interface hash (and not an "implementation" hash.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 05:35:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 05:35:11 -0000 Subject: [GHC] #11377: Template Haskell only imports Message-ID: <045.7f717f9d66578f30b0c37a668b428368@haskell.org> #11377: Template Haskell only imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Template | Version: 7.11 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: -------------------------------------+------------------------------------- This is the Template Haskell equivalent of #11244. It should be possible to use the plugin package database to make a Template Haskell only import; I suggest the syntax `import {-# TH_ONLY #-} Foo`. Such imports are only allowed to be used in splices, and cannot be quoted (they are not allowed to reside in the final code generated by the splice.) The reason a user may want to use such an import is that it means that they can declare that a library is necessary when compiling splices, but not necessary when actually linking against it. There are extra benefits. If a user is compiling the package with the splices with profiling, it ordinarily requires all imports to have been compiled with profiling. This would NOT be necessary for a `TH_ONLY` import, since we're only ever going to run the imported code in the (non- profiled) compiler, and not in the (profiled) executable.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 06:08:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 06:08:59 -0000 Subject: [GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling Message-ID: <045.6104ef63780cb1088603ac8080468c98@haskell.org> #11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: ? Component: Template | Version: 7.11 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: -------------------------------------+------------------------------------- In a non cross-compiled stage 2 compiler, this coincides with what we do today, because the stage 1 implementation of GHC is the same as the stage 2 implementation. But in a cross-compiler, these are NOT the same: the cross-compiler's ghc library handles the package database in the target platform, whereas the compiler that built stage 2 (stage 1)'s ghc library handles the package database for the compiler's platform. So, the correct architecture for supporting compiler plugins is that GHC should use the package-database/interface infrastructure from the compiler which built it (stage 1) to handle loading. A few things to note: 1. There is not a backwards-compatibility problem, because we can assume that stage 1 and stage 2 are built from the same codebase. In particular, this does NOT mean that TH/plugins start working on a stage 1 compiler. You have to have bootstrapped from the same codebase. 2. Plugins (and even Template Haskell) have to be a bit more careful to take advantage of this. We cannot just assume that the package database for plugins is the same as the package database for compiling (revisiting #11244). Template Haskell is even trickier: we should NOT be allowed to use regular imports in splices; they have to go through `TH_ONLY` imports, c.f. #11377 3. Can we actually link against the old version of `ghc`? Yes we can! All we need is (1) for it to have been built with a different IPID, and (2) to use module renaming to rename the relevant modules to a different module name, so that we can import them without a conflict. Stepping back, there have been two approaches for dealing with the problem of Template Haskell/compiler plugins not reliably working: 1. Run the code in an external process run in the target code, or 2. Fix GHC to load code which is appropriately built for the bootstrap platform. While (1) offers a more uniform environment for developers, (2) is absolutely necessary in some situations when you need to load code in the same address space as GHC, e.g. as mentioned in https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html Thus, it seems worth pursuing both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 08:00:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 08:00:16 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.8336516eba28d576bcdd41fefca288fb@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Comment (by Phyx-): Oh I see. The `EXIT_HEAPOVERFLOW` is returned directly from there. Then this should be trivial to fix for Windows. Just have to pass the correct exit codes to `stg_exit` here https://github.com/ghc/ghc/blob/master/rts/win32/veh_excn.c#L65 I'll take care of that tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 08:32:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 08:32:51 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.ed1ee5618e875bd0193e9c60f905c146@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 jstolarek): alexvieth, could you upload your patches to [https://phabricator.haskell.org Phab]? This is our preferred method of uploading and reviewing patches. See also this wiki page: [wiki:Phabricator]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 08:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 08:50:40 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.a1a8c1746a5b67b461457b688a08a8f4@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"6be09e884730f19da6c24fc565980f515300e53c/ghc" 6be09e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6be09e884730f19da6c24fc565980f515300e53c" Enable stack traces with ghci -fexternal-interpreter -prof Summary: The main goal here is enable stack traces in GHCi. After this change, if you start GHCi like this: ghci -fexternal-interpreter -prof (which requires packages to be built for profiling, but not GHC itself) then the interpreter manages cost-centre stacks during execution and can produce a stack trace on request. Call locations are available for all interpreted code, and any compiled code that was built with the `-fprof-auto` familiy of flags. There are a couple of ways to get a stack trace: * `error`/`undefined` automatically get one attached * `Debug.Trace.traceStack` can be used anywhere, and prints the current stack Because the interpreter is running in a separate process, only the interpreted code is running in profiled mode and the compiler itself isn't slowed down by profiling. The GHCi debugger still doesn't work with -fexternal-interpreter, although this patch gets it a step closer. Most of the functionality of breakpoints is implemented, but the runtime value introspection is still not supported. Along the way I also did some refactoring and added type arguments to the various remote pointer types in `GHCi.RemotePtr`, so there's better type safety and documentation in the bridge code between GHC and ghc-iserv. Test Plan: validate Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1747 GHC Trac Issues: #11047, #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 08:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 08:50:40 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.6d00fc640c384f4c58e9fe3d75505a3f@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"6be09e884730f19da6c24fc565980f515300e53c/ghc" 6be09e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6be09e884730f19da6c24fc565980f515300e53c" Enable stack traces with ghci -fexternal-interpreter -prof Summary: The main goal here is enable stack traces in GHCi. After this change, if you start GHCi like this: ghci -fexternal-interpreter -prof (which requires packages to be built for profiling, but not GHC itself) then the interpreter manages cost-centre stacks during execution and can produce a stack trace on request. Call locations are available for all interpreted code, and any compiled code that was built with the `-fprof-auto` familiy of flags. There are a couple of ways to get a stack trace: * `error`/`undefined` automatically get one attached * `Debug.Trace.traceStack` can be used anywhere, and prints the current stack Because the interpreter is running in a separate process, only the interpreted code is running in profiled mode and the compiler itself isn't slowed down by profiling. The GHCi debugger still doesn't work with -fexternal-interpreter, although this patch gets it a step closer. Most of the functionality of breakpoints is implemented, but the runtime value introspection is still not supported. Along the way I also did some refactoring and added type arguments to the various remote pointer types in `GHCi.RemotePtr`, so there's better type safety and documentation in the bridge code between GHC and ghc-iserv. Test Plan: validate Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1747 GHC Trac Issues: #11047, #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 08:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 08:50:40 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.eb9781cbeb5a37ea273455eeaf1b64b8@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"09425cbe4fb93ac3af4932937478d46972ecf91f/ghc" 09425cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="09425cbe4fb93ac3af4932937478d46972ecf91f" Support for qRecover in TH with -fexternal-interpreter Summary: This completes the support for TH with -fexternal-interpreter. Test Plan: validate Reviewers: bgamari, ezyang, austin, niteria, goldfire, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1748 GHC Trac Issues: #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 08:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 08:54:17 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.b6c64ddbd880db2d15ec431347991645@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Comment (by simonmar): The last missing functionality is the GHCi debugger, everything else should now work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 09:03:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 09:03:33 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.6316862b14c6ea3392200046a5466bef@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: merge Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge Comment: Ben, could we get 6be09e884730f19da6c24fc565980f515300e53c merged into 8.0? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 09:10:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 09:10:32 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.928f2160a68b7e38cd8963caa1d3aa80@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: merge Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 09:34:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 09:34:44 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.4eb9b3377609fa75441631b1edb3b701@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 10:10:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 10:10:18 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.c4fee9030bfca5b04b3ad68ea22cdb46@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T11341 Blocked By: | Blocking: Related Tickets: #10828 #10719 | Differential Rev(s): Phab:D1738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * related: #10828 => #10828 #10719 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 10:27:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 10:27:04 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.2da1b8ea0a46abbb574e7ecedcfef2f1@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.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 jstolarek: Old description: > This is accepted: > > Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A where C > :: C |])}}} > > "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" > > In contrast this is rejected: > Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A p where C > :: C |])}}} > > :29:22: Malformed constructor result type: C > > However it would make sense to form an equality constraint (for later > kind/type checking) in these cases, something along the lines of: > {{{#!hs > data A p where > C :: (A p ~ C) => C > }}} > as there could be type synonym (or family) `C`. > > I have tested various versions >= 7.8.3 and all seem to behave the same. New description: This is accepted: {{{ Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A where C :: C |])}}} "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" }}} In contrast this is rejected: {{{ Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A p where C :: C |])}}} :29:22: Malformed constructor result type: C }}} However it would make sense to form an equality constraint (for later kind/type checking) in these cases, something along the lines of: {{{#!hs data A p where C :: (A p ~ C) => C }}} as there could be type synonym (or family) `C`. I have tested various versions >= 7.8.3 and all seem to behave the same. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 10:29:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 10:29:14 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.415dad8da049a2591a191ca160bb9f15@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.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 jstolarek: Old description: > This is accepted: > > {{{ > Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A where C > :: C |])}}} > > "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" > }}} > > In contrast this is rejected: > > {{{ > Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A p where C > :: C |])}}} > > :29:22: Malformed constructor result type: C > }}} > > However it would make sense to form an equality constraint (for later > kind/type checking) in these cases, something along the lines of: > {{{#!hs > data A p where > C :: (A p ~ C) => C > }}} > as there could be type synonym (or family) `C`. > > I have tested various versions >= 7.8.3 and all seem to behave the same. New description: This is accepted: {{{ Prelude Language.Haskell.TH> $(stringE . show =<< [d| data A where C :: C |]) "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" }}} In contrast this is rejected: {{{ Prelude Language.Haskell.TH> $(stringE . show =<< [d| data A p where C :: C |]) :29:22: Malformed constructor result type: C }}} However it would make sense to form an equality constraint (for later kind/type checking) in these cases, something along the lines of: {{{#!hs data A p where C :: (A p ~ C) => C }}} as there could be type synonym (or family) `C`. I have tested various versions >= 7.8.3 and all seem to behave the same. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 10:33:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 10:33:08 -0000 Subject: [GHC] #11379: New superclass solver fails to compile Message-ID: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> #11379: New superclass solver fails to compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- This example (derived from `xmonad-contrib`) failed to compile with `master`, {{{#!hs {-# LANGUAGE ExistentialQuantification, RankNTypes, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, FlexibleContexts #-} module XMonad.Layout.MultiToggle where import Data.Typeable -- This appears to be the culprit expand :: (HList ts a) => MultiToggleS ts l a -> MultiToggle ts l a expand (MultiToggleS b ts) = resolve ts id (\x mt -> let g = transform' x in mt{ currLayout = g $ currLayout mt }) (MultiToggle (EL b id) ts) class (Typeable t) => Transformer t a | t -> a where transform :: t -> l a -> (forall l'. l' a -> (l' a -> l a) -> b) -> b data EL l a = forall l'. EL (l' a) (l' a -> l a) transform' :: (Transformer t a) => t -> EL l a -> EL l a transform' t (EL l det) = undefined data MultiToggleS ts l a = MultiToggleS (l a) ts deriving (Read, Show) data MultiToggle ts l a = MultiToggle{ currLayout :: EL l a, transformers :: ts } class HList c a where resolve :: c -> b -> (forall t. (Transformer t a) => t -> b) -> b }}} failing during constraint solving with,, {{{ XMonad/Layout/MultiToggle.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Transformer t a (CDictCan) [D] _ :: a_aIoy ~ a (CNonCanonical) [D] _ :: Typeable t (CDictCan) wc_impl = Implic { TcLevel = 7 Skolems = (l :: * -> *) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [W] $dTransformer_aIoM :: Transformer t a (CDictCan)} Binds = Just EvBindsVar the inferred type of g :: EL l_aIoL a_aIoK -> EL l_aIoL a_aIoK }} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Lifting the solver iteration limit just results in a loop. I suspect the issue may be in the `Typeable` solving logic, as removing the `Typable` constraint from `Transformer`'s head allows compilation to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 10:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 10:42:44 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints (was: New superclass solver fails to compile) In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.bad7aa5470ddf21b18d689402936deb6@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 10:43:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 10:43:39 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.195553911a52308f5ad4d5ee00160c8a@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 bgamari: Old description: > This example (derived from `xmonad-contrib`) failed to compile with > `master`, > > {{{#!hs > {-# LANGUAGE ExistentialQuantification, RankNTypes, > MultiParamTypeClasses, > FunctionalDependencies, FlexibleInstances, FlexibleContexts > #-} > > module XMonad.Layout.MultiToggle where > > import Data.Typeable > > -- This appears to be the culprit > expand :: (HList ts a) => MultiToggleS ts l a -> MultiToggle ts l a > expand (MultiToggleS b ts) = > resolve ts id > (\x mt -> let g = transform' x in mt{ currLayout = g $ currLayout > mt }) > (MultiToggle (EL b id) ts) > > class (Typeable t) => Transformer t a | t -> a where > transform :: t > -> l a > -> (forall l'. l' a -> (l' a -> l a) -> b) > -> b > > data EL l a = forall l'. EL (l' a) (l' a -> l a) > > transform' :: (Transformer t a) => t -> EL l a -> EL l a > transform' t (EL l det) = undefined > > data MultiToggleS ts l a = MultiToggleS (l a) ts > deriving (Read, Show) > > data MultiToggle ts l a = MultiToggle{ > currLayout :: EL l a, > transformers :: ts > } > > class HList c a where > resolve :: c -> b -> (forall t. (Transformer t a) => t -> b) -> b > }}} > > failing during constraint solving with,, > > {{{ > XMonad/Layout/MultiToggle.hs:1:1: error: > solveWanteds: too many iterations (limit = 4) > Unsolved: WC {wc_simple = > [D] _ :: Transformer t a (CDictCan) > [D] _ :: a_aIoy ~ a (CNonCanonical) > [D] _ :: Typeable t (CDictCan) > wc_impl = > Implic { > TcLevel = 7 > Skolems = (l :: * -> *) > No-eqs = True > Status = Unsolved > Given = > Wanted = > WC {wc_simple = > [W] $dTransformer_aIoM :: Transformer t a > (CDictCan)} > Binds = Just EvBindsVar > the inferred type of g :: EL l_aIoL a_aIoK -> EL > l_aIoL a_aIoK }} > New superclasses found > Set limit with -fconstraint-solver-iterations=n; n=0 for no limit > }}} > > Lifting the solver iteration limit just results in a loop. > > I suspect the issue may be in the `Typeable` solving logic, as removing > the `Typable` constraint from `Transformer`'s head allows compilation to > proceed. New description: This example (derived from `xmonad-contrib`) failed to compile with `master`, {{{#!hs {-# LANGUAGE ExistentialQuantification, RankNTypes, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, FlexibleContexts #-} module XMonad.Layout.MultiToggle where import Data.Typeable -- This appears to be the culprit expand :: (HList ts a) => MultiToggleS ts l a -> MultiToggle ts l a expand (MultiToggleS b ts) = resolve ts id (\x mt -> let g = transform' x in mt{ currLayout = g $ currLayout mt }) (MultiToggle (EL b id) ts) -- Removing the Typeable constraint here allows compilation to finish class (Typeable t) => Transformer t a | t -> a where transform :: t -> l a -> (forall l'. l' a -> (l' a -> l a) -> b) -> b data EL l a = forall l'. EL (l' a) (l' a -> l a) transform' :: (Transformer t a) => t -> EL l a -> EL l a transform' t (EL l det) = undefined data MultiToggleS ts l a = MultiToggleS (l a) ts deriving (Read, Show) data MultiToggle ts l a = MultiToggle{ currLayout :: EL l a, transformers :: ts } class HList c a where resolve :: c -> b -> (forall t. (Transformer t a) => t -> b) -> b }}} failing during constraint solving with,, {{{ XMonad/Layout/MultiToggle.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Transformer t a (CDictCan) [D] _ :: a_aIoy ~ a (CNonCanonical) [D] _ :: Typeable t (CDictCan) wc_impl = Implic { TcLevel = 7 Skolems = (l :: * -> *) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [W] $dTransformer_aIoM :: Transformer t a (CDictCan)} Binds = Just EvBindsVar the inferred type of g :: EL l_aIoL a_aIoK -> EL l_aIoL a_aIoK }} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Lifting the solver iteration limit just results in a loop. I suspect the issue may be in the `Typeable` solving logic, as removing the `Typable` constraint from `Transformer`'s head allows compilation to proceed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:02:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:02:11 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.c26cc8d045f866f1cc90e1f295772cdc@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11341 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #11341 Comment: Representation of GADTs has changed (#11341) since this was reported. Now we get: {{{ ghci> $(stringE . show =<< [d| data A where C :: C |]) "[DataD [] A_1627425412 [] Nothing [GadtC [C_1627425413] [] (PromotedT C_1627425413)] []]" ghci> $(stringE . show =<< [d| data A p where C :: C |]) "[DataD [] A_1627426432 [PlainTV p_1627426434] Nothing [GadtC [C_1627426433] [] (PromotedT C_1627426433)] []]" ghci> $(stringE . show =<< [d| type C = A; data A x where C :: 'C Int |]) "[ TySynD C_1627426587 [] (ConT A_1627426585) , DataD [] A_1627426585 [PlainTV x_1627426588] Nothing [GadtC [C_1627426586] [] (AppT (PromotedT C_1627426586) (ConT GHC.Types.Int))] []]" ghci> $(stringE . show =<< [d| data A x where C :: 'C Int |]) "[DataD [] A_1627426731 [PlainTV x_1627426733] Nothing [GadtC [C_1627426732] [] (AppT (PromotedT C_1627426732) (ConT GHC.Types.Int))] []]" }}} I believe that quoting works correctly here. Note also that all four definitions are invalid and they are correctly rejected by HEAD if you quote them and splice them in immediately. (Also, (3) and (4) are semantically equivalent since the type synonym is not used in any way.) This definition is also rejected by HEAD: {{{#!hs data A p where C :: (A p ~ C) => C }}} Unless I am missing something, I would close this report as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:03:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:03:13 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.c93d33e868bd2d2bce01a480cf9b7a97@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11341, #10828 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: #11341 => #11341, #10828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:25:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:25:30 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.9674eedef7d6dc03ce6b6e5c6b01813f@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0163427761c0e72a3acf09f854b3447f2e553f1b/ghc" 01634277/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0163427761c0e72a3acf09f854b3447f2e553f1b" Fix Template Haskell's handling of infix GADT constructors This is the second (and hopefully last) fix needed to make TH handle GADTs properly (after D1465). This Diff addresses some issues with infix GADT constructors, specifically: * Before, you could not determine if a GADT constructor was declared infix because TH did not give you the ability to determine if there is a //user-specified// fixity declaration for that constructor. The return type of `reifyFixity` was changed to `Maybe Fixity` so that it yields `Just` the fixity is there is a fixity declaration, and `Nothing` otherwise (indicating it has `defaultFixity`). * `DsMeta`/`Convert` were changed so that infix GADT constructors are turned into `GadtC`, not `InfixC` (which should be reserved for Haskell98 datatype declarations). * Some minor fixes to the TH pretty-printer so that infix GADT constructors will be parenthesized in GADT signatures. Fixes #11345. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, jstolarek Reviewed By: jstolarek Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1744 GHC Trac Issues: #11345 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:25:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:25:30 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.652e6f13fad2cc14582d6172c9e44e97@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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: | Differential Rev(s): Phab:D1742 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1abb7005067e22039807de34cd60bed55316e925/ghc" 1abb7005/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1abb7005067e22039807de34cd60bed55316e925" Improve GHC.Event.IntTable performance Speed up GHC.Event.IntTable.lookup by removing the IO context from the go helper function. This generates a little bit better code as we can avoid repeating the stack check. Remove unused parameter from GHC.Event.IntTable.updateWith.go and directly return a bool instead of a maybe and then checking that whether it is a Nothing. Test Plan: validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1742 GHC Trac Issues: #8793 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:36:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:36:11 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.7c44ede34672d72cd33bba5e3dc7ffd3@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, simonpj (added) * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:45:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:45:51 -0000 Subject: [GHC] #11380: `cabal repl` exhausts memory Message-ID: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> #11380: `cabal repl` exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a project that depends on happy/alex to generate parsers. (https://github.com/TOSPIO/pyn) Running `cabal repl` on my laptop (Gentoo Linux amd64) with 16GiB memory ended up eating up all memory and eventually resulted in kernel panic. `cabal build` works fine. Problem arises when compiling the giant happy- generated dist/build/Language/Python/Parser/Parse.hs file also `cabal repl --ghc-options=-fobject-code` works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 11:46:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 11:46:23 -0000 Subject: [GHC] #11380: `cabal repl` exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.f519eefd0f86664448bc2df7810d3ad1@haskell.org> #11380: `cabal repl` exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kennethb): * os: Unknown/Multiple => Linux Old description: > I have a project that depends on happy/alex to generate parsers. > (https://github.com/TOSPIO/pyn) > > Running `cabal repl` on my laptop (Gentoo Linux amd64) with 16GiB memory > ended up eating up all memory and eventually resulted in kernel panic. > > `cabal build` works fine. Problem arises when compiling the giant happy- > generated dist/build/Language/Python/Parser/Parse.hs file > > also `cabal repl --ghc-options=-fobject-code` works fine. New description: I have a project that depends on happy/alex to generate parsers. (https://github.com/TOSPIO/pyn) Running `cabal repl` on my laptop with 16GiB memory ended up eating up all memory and eventually resulted in kernel panic. `cabal build` works fine. Problem arises when compiling the giant happy- generated dist/build/Language/Python/Parser/Parse.hs file also `cabal repl --ghc-options=-fobject-code` works fine. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 12:03:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 12:03:18 -0000 Subject: [GHC] #11381: Put injective type families in a separate language extension Message-ID: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> #11381: Put injective type families in a separate language extension -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #6018 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Injective type families should only be enabled when language extension `InjectiveTypeFamilies` is specified. This extension should imply `TypeFamilies`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 13:14:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 13:14:06 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.8251645daccf16551f6b32e824d5c706@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 niteria): * owner: niteria => Comment: I know what causes it to fail, but I don't know what a good fix would be, leaving for someone else to claim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 13:49:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 13:49:09 -0000 Subject: [GHC] #11382: Optimize Data.Char Message-ID: <046.07b85d059cbd81601867717299b83062@haskell.org> #11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 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: -------------------------------------+------------------------------------- Many of the predicates in `Data.Char` do full Unicode category lookups which turns out to be quite expensive. Ideally we would handle some of the more common ASCII characters with cheaper tests before falling back to the full Unicode treatment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 14:04:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 14:04:38 -0000 Subject: [GHC] #11304: Programs compiled with GHC master segfault when run with +RTS -h In-Reply-To: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> References: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> Message-ID: <061.a5363f171cf1b675b3ba9730faa7ae89@haskell.org> #11304: Programs compiled with GHC master segfault when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 Simon Marlow ): In [changeset:"c33e7c2b1a62f340432c752fb37ca1374e3e982a/ghc" c33e7c2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c33e7c2b1a62f340432c752fb37ca1374e3e982a" Fix +RTS -h when compiling without -prof Summary: Was broken by ce1f1607ed7f8fedd2f63c8610cafefd59baaf32. I've added a test so that hopefully it won't break again. Test Plan: validate & new test case Reviewers: bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1746 GHC Trac Issues: #11304 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 14:05:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 14:05:32 -0000 Subject: [GHC] #11304: Programs compiled with GHC master segfault when run with +RTS -h In-Reply-To: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> References: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> Message-ID: <061.38275287f37d6b3b1b52b17432df9035@haskell.org> #11304: Programs compiled with GHC master segfault when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 14:56:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 14:56:42 -0000 Subject: [GHC] #11281: Way to run --make and -M simultaneously In-Reply-To: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> References: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> Message-ID: <060.0a3a6193906fdf4f0ef9715716c91ec5@haskell.org> #11281: Way to run --make and -M simultaneously -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: | -------------------------------------+------------------------------------- Comment (by thomie): Equivalent `gcc` (5.2.0) flag: {{{ -MD -MD is equivalent to -M -MF file, except that -E is not implied. The driver determines file based on whether an -o option is given. If it is, the driver uses its argument but with a suffix of .d, otherwise it takes the name of the input file, removes any directory components and suffix, and applies a .d suffix. If -MD is used in conjunction with -E, any -o switch is understood to specify the dependency output file, but if used without -E, each -o is understood to specify a target object file. Since -E is not implied, -MD can be used to generate a dependency output file as a side-effect of the compilation process. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 15:03:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 15:03:41 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks Message-ID: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 implicit call stack machinery adds a constraint to CAFs, which loses sharing in some cases. The regression is fixed by -O (actually `-ffull- laziness`), but it is surprising nonetheless, and might cause problems for people using GHCi or other places where -O is turned off. For example: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} module Main where import System.Environment fib :: Integer -> Integer fib n = if n < 2 then 1 else fib (n-1) + fib (n-2) x = if fib 3 > 20 then error "x" else fib 30 main = do [n] <- getArgs case n of "a" -> print (x + x) "b" -> print x }}} Try it as follows (requires 8.0+): {{{ $ ghc imp.hs -fforce-recomp -O -fno-full-laziness $ ./imp a +RTS -t 2692538 <> $ ./imp b +RTS -t 1346269 <> }}} With GHC 7.10 and earlier both commands perform the same. Note that this only uses `error`, and doesn't require `ImplicitParams`. It does require `NoMonomorphismRestriction`, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 15:06:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 15:06:47 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.0814ace8b79711ea446e96c0de4cb29d@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): We may or may not consider this a bug, so I'm reporting it for discussion. Arguably it's the same as using any overloaded function in a CAF together with `NoMonomorphismRestriction`, the surprising bit is that `error` is now "overloaded". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 16:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 16:13:26 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.671830d43070b96f694850a60386912b@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Changes (by simonmar): * cc: Phyx- (added) Comment: @Phyx-, I don't know if you're interested in looking at this, but there's a bit of Windows-specific hacking needed to get this working for Windows. We use pipes directly to communicate between GHC and the ghc-iserv process, and there's currently no library support to do this on Windows. `System.Process` rolls its own, but it's not reusable directly. Starting place is `iserv/Main.hs` and `compiler/ghci/GHCi.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 16:19:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 16:19:57 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.5e2910fed0bb09a4a10482bd5214ba7d@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact 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 varosi): Is Report is showing a possibility to read ".9" as Double? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 16:27:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 16:27:17 -0000 Subject: [GHC] #11381: Put injective type families in a separate language extension In-Reply-To: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> References: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> Message-ID: <063.222ce4c32ba723ad6ea18ee86e6ad371@haskell.org> #11381: Put injective type families in a separate language extension -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeFamilies, | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T11381 Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1750 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => driver/T11381 * differential: => Phab:D1750 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 16:38:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 16:38:41 -0000 Subject: [GHC] #11384: Error says to fix incorrect return type Message-ID: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> #11384: Error says to fix incorrect return type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Defining a constructor that returns the wrong type (non-parent type). If the constructor is not fully-applied or over-saturated GHC reports an error, instead of telling the developer to change the return type: {{{ Prelude> data A Prelude> data B a where MkB :: A () :2:23: error: ? Expecting one fewer argument to ?A? Expected kind ?* -> *?, but ?A? has kind ?*? ? In the type ?A ()? In the definition of data constructor ?MkB? In the data declaration for ?B? }}} Expected: 1. Suggest GADTs: {{{ ? Illegal generalised algebraic data declaration for ?B? (Use GADTs to allow GADTs) ? In the data declaration for ?B? }}} 2. Complain about incorrect return type: {{{ ? Data constructor ?MkB? returns type ?A? instead of an instance of its parent type ?B a? ? In the definition of data constructor ?MkB? In the data type declaration for ?B? }}} It shouldn't suggest the user fix the incorrect return type -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 16:58:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 16:58:26 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.00cff2a1bf621046cb3164c1e7e0f4cb@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9180, #9636 | Differential Rev(s): Phab:D1236 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I embellished the documentation a bit in 568736d757d3e0883b0250e0b948aeed646c20b5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 17:14:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 17:14:39 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.a71c5368b81929bf3147da42cd2b3219@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * related: => #11298 Comment: As you said, this is really just the monomorphism restriction (or in this case the lack thereof) at work. The two pieces that contribute to this behavior are: 1. `error` is now overloaded with an implicit parameter, the call-stack. 2. GHC infers implicit parameters (including call-stacks) as needed, unless there's an explicit signature or the monomorphism restriction applies. There's a similar report in #11298, see the two definitions of `fooHelper`. We could avoid this (potentially confusing) behavior for the most part by not inferring call-stacks for top-level definitions. I'm a bit reluctant to do so because it makes call-stacks less like implicit parameters, and would require another special case in the type-checker. One of the things I like about the current version of the call-stack solver is how similar implicit call-stacks are to regular implicit parameters. --- I'm actually more concerned about the fact that `-ffull-laziness` changes the behavior. Does this mean we're caching the first call-stack? That would be completely wrong; it would be wrong for any implicit parameter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 19:47:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 19:47:07 -0000 Subject: [GHC] #11382: Optimize Data.Char In-Reply-To: <046.07b85d059cbd81601867717299b83062@haskell.org> References: <046.07b85d059cbd81601867717299b83062@haskell.org> Message-ID: <061.b0bcbdeabd01c5d0252283f786e411a1@haskell.org> #11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.3 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 ekmett): Didn't David Feuer try some things along this line? I seem to recall the branching overhead to split off the ASCII cases was hard to overcome in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 20:12:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 20:12:09 -0000 Subject: [GHC] #11382: Optimize Data.Char In-Reply-To: <046.07b85d059cbd81601867717299b83062@haskell.org> References: <046.07b85d059cbd81601867717299b83062@haskell.org> Message-ID: <061.4c7dcd50c50b31f8efe8f522f455e23a@haskell.org> #11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9638 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dfeuer (added) * related: => #9638 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 20:30:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 20:30:15 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.8a4dbe6088dfee4f4d98f8cc25c776e3@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): `-ffull-laziness` lifts the expensive computation outside the implicit parameter, so recovering the sharing that was lost by the introduction of the implicit parameter constraint. It doesn't change the meaning. This is only an issue for CAFs, because functions already have a lambda at the outside so there's no sharing to lose. (CAFs are a notorious problem for stack tracing, incidentally, because you get to choose between losing sharing and losing information) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 20:35:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 20:35:01 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.87dbd2488404643769018296b7c11ffc@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I suppose if what you were trying to share was itself something that had an implicit call stack parameter, then full-laziness wouldn't be able to fix it. Which is a bigger problem, but still arguably the same issue that the monomorphism restriction was intended to fix. The user gets to choose between having sharing or a call stack when they write the type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 20:35:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 20:35:59 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.ed762372c755ec2425f315becb9cf357@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: invalid | Keywords: Read, report- | impact 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 ekmett): * status: new => closed * resolution: => invalid Comment: The lexical syntax specified in the Haskell 98 Report here: https://www.haskell.org/onlinereport/syntax-iso.html#sect9.2 gives {{{ float -> decimal . decimal [exponent] | decimal exponent }}} A change to the report here would haphazardly change the semantics and behavior of code that currently typecheck. Like it or not, in the presence of the rather common {{{#!hs instance Num b => Num (a -> b) where f + g = \x -> f x + g x fromIntegral n = \x -> fromIntegral n ... }}} then `(.9)` parses today as precomposition with the constant function that returns 9. `abs .9` is a composition of abs and the function you obtain above from 9, etc. In the absence of such a change to the Haskell Report I'd say we should close this as a `invalid` (or `wontfix`) as it steps outside of the mandate of `read` for the language as it exists. From the standpoint of the libraries committee I'm going to close this out as such. In the unlikely event that the haskell-prime committee changes the language we have such that .9 parses as a `Fractional` value then we'd be faced with the dilemma of how to support both old and new standards on the library front. Feel free to reopen this if that happens and we'll be forced to figure out what to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 22:24:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 22:24:48 -0000 Subject: [GHC] #11385: Unify named wildcards in different type applications Message-ID: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> #11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple NamedWildCards TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ([https://www.reddit.com/r/haskell/comments/4030lv/unifying_distinct_type_variables_in/ motivating post]) I would like to use type application to specialize {{{#!hs Sub :: forall (a :: Constraint) (b :: Constraint). (a => Dict b) -> a :- b Sub @(Ord _a) @(Eq _a) :: forall {a}. (Ord a => Dict (Eq a)) -> Ord a :- Eq a }}} and {{{#!hs map :: forall a b. (a -> b) -> [a] -> [b] map @_a @_a :: forall {a}. (a -> a) -> [a] -> [a] }}} Is there a fundamental reason why named wildcards are not allowed to unify between type applications within the same expression? [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #named-wildcards Documentation]: > These are called named wildcards. All occurrences of the same named wildcard within one type signature will unify to the same type. I don't know if this is intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 8 22:46:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jan 2016 22:46:31 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.bd83f7fc6b0ffd13d6c2f4bfb83b7a77@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact 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 varosi): * status: closed => new * resolution: invalid => Comment: Here the problem is not in the GHC itself, but in Prelude with parsing of strings using Read type class: (read ".9") :: Double -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 00:27:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 00:27:26 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.dd4c579f2b5269f45f37ecf90e023d20@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: wontfix | Keywords: Read, report- | impact 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 carter): * status: new => closed * resolution: => wontfix Comment: 1) i understand the nature of your request, you do not need to explain it further 2) the purpose of read / show are to provide basic round tripping facilities for naive debugging / printing of haskell data structures, 3) for complicated data structures, accepting ".9" as valid would create some room for more ambiguity in parsing 4) as a further piece of anecdata for why this would be a terrible change, in a work code base, the fact that attoparsec accepts floats in this format created some incredibly hard to resolve bugs in a streaming parsing facility. So from that perspective since this seems to mostly an aesthetical feature request, i suggest you write you own either a) read instance for a newtype'd double, OR use a different parsing library that suites your goals, such as attoparsec :) for core core data types such as floating point, breaking changes to how built in parsing facilities work must be done with utmost consideration. I actually took the time to check the 2008 IEEE Floating point standard, and it doesn't specify this. The only format support that is mandated by the IEEE 2008 floating point standard is support for reading/writing floating point numbers in hexadecimal notation. The specification therein does allow terms of the form "0x.9" or "0X.9", but those are MUCH MUCH less ambiguous than ".9" in terms of possible parsing interpretations, and is infact a very very reasonable part of the standard because that is precisely a finite representation that has zero rounding between the internal binary representation of finite numbers and a hexadecimal floating point string presentation. Several folks have now all agreed that for a miscellany of reasons that your feature request is invalid. It would be valid to explore adding hexadecimal floating point read/show support, though that could itself have parsing implications that'd need be understood, but doesn't face the same parsing ambiguities, AND is actually specified by the underlying floating point standard. (just because the C11 language standard specifies that ".1" is a valid floating point literal doesn't justify that we do, and the read instances for haskell base SHOULD / MUST match what are acceptable literals for the source, and because the code for read/show does't change with the language extensions enabled, it MUST match what is specified in the haskell language standard) point of record: haskell language defines float lexical terms as {{{ float ? decimal . decimal [exponent] | decimal exponent }}} likewise, the hexformat in the 2008 IEEE floating point standard is {{{ sign digit hexDigit hexExpIndicator hexIndicator hexSignificand decExponent hexSequence [+ ?] [0123456789] [0123456789abcdefABCDEF] [Pp] "0" [Xx] ( {hexDigit} * "." {hexDigit}+ | {hexDigit}+ "." | {hexDigit}+ ) {hexExpIndicator} {sign}? {digit}+ {sign}? {hexIndicator} {hexSignificand} {decExponent} }}} where each line is a name followed by a rule in which ?[...]? selects one of the terminal characters listed between the brackets, ?{...}? refers to an earlier named rule, ?(... | ... | ...)? indicates a choice of one of three alternatives, straight double quotes enclose a terminal character, ??? indicates that there shall be either no instance or one instance of the preceding item, ?*? indicates that there shall be zero or more instances of the preceding item, and ?+? indicates that there shall be one or more instances of the preceding item. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 07:21:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 07:21:19 -0000 Subject: [GHC] #11386: Improve error message Message-ID: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{ Prelude> class (A, B) :16:8: error: Unexpected type ?A? In the class declaration for ?GHC.Classes.(%,%)? A class declaration should have form class GHC.Classes.(%,%) a b where ... }}} in 7.10.2 it gave the more sensible {{{ ghci> class (A, B) :30:7: Malformed head of type or class declaration: (A, B) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 08:53:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 08:53:35 -0000 Subject: [GHC] #11386: Improve error message In-Reply-To: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> References: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> Message-ID: <066.35376b8ef07084351f8026e0274a27c4@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10362 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #10362 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 08:54:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 08:54:37 -0000 Subject: [GHC] #11386: Improve error message In-Reply-To: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> References: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> Message-ID: <066.e97653aaf968030f09e461124cddbc34@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10362 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Simon says "There should be no user-visible effects." in ticket #10362. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 08:56:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 08:56:51 -0000 Subject: [GHC] #10362: Make tuple constraints into a class In-Reply-To: <046.37ffd03861c08e5d28fe4001f4a37725@haskell.org> References: <046.37ffd03861c08e5d28fe4001f4a37725@haskell.org> Message-ID: <061.1c4b9200cc96d92d538f542acaecf6ef@haskell.org> #10362: Make tuple constraints into a class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Affects error messages: #11386 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 09:18:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 09:18:35 -0000 Subject: [GHC] #11380: `cabal repl` exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.24183b05d41f831e68ee14799858f938@haskell.org> #11380: `cabal repl` exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kennethb): * version: 7.10.2 => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 09:36:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 09:36:21 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.cf362aab66b2ac6b2425c8a8f1337e8e@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This can also be faked using prisms and pattern synonyms: [https://www.reddit.com/r/haskell/comments/38owdh/question_would_an_associated_data_constructor_be/crxnn71 reddit comment]. For visible type application in patterns per [comment:7 Richard's comment] see #11350. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 09:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 09:50:46 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.42170fbfcef1582be1772c3c18692c96@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms 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 Iceland_jack): This ''should'' make the code in [https://ghc.haskell.org/trac/ghc/ticket/8583#comment:7 Richard's comment] compile: {{{#!hs headOfList :: forall a. [a] -> Maybe a headOfList (Nil @[] @a) = Nothing @a headOfList (Cons @[] @a x _) = Just x }}} The rest of his comment applies to, this is not for dynamically branching on types although that could certainly be added as a feature! {{{#!hs doubleWhenInt :: forall a. Typeable a => a -> a doubleWhenInt a = case eqT @Int @a of Just Refl -> a + a Nothing -> a -- Becomes? doubleWhenInt :: forall a. Typeable a => a -> a doubleWhenInt @Int n = n + n doubleWhenInt @_ a = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 09:53:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 09:53:58 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.195967fe522ed6439478a026c88ce908@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Comment (by trommler): Replying to [comment:34 hgolden]: > Replying to [comment:29 trommler]: > > See Phab:1631 for details. > The link above doesn't work. Phab:D1631 is correct. Fixed. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 10:05:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 10:05:19 -0000 Subject: [GHC] #11387: Typecasting using type application syntax Message-ID: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> #11387: Typecasting using type application syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11350 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I created #11350 to allow visible (static) type applications in patterns. I had a [https://ghc.haskell.org/trac/ghc/ticket/11350#comment:2 thought] about translating non-parametric type applications in patterns as a runtime type check (`Typeable`) and decided to create a ticket in case it made any sense. Example: {{{#!hs doubleWhenInt :: forall a. Typeable a => a -> a doubleWhenInt x = case eqT @Int @a of Just Refl -> x + x Nothing -> x -- Becomes? doubleWhenInt :: Typeable a => a -> a doubleWhenInt @Int n = n + n doubleWhenInt @_ x = x }}} Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 10:16:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 10:16:07 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.e6e5b6c6a5c1b70ca8995c54a8c75d75@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:19 simonmar]: > We require the `-dev` versions of libraries for GHCi very deliberately, because GHCi is supposed to mimic the linking that would be done for a standalone executable. OK. So the in the dynamic case GHCi SHOULD NOT (MUST NOT?) require the presence of the development versions of C libraries when using an installed Haskell package. This is currently not the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 10:40:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 10:40:18 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.e6e025f3713d36a823fe883631a992e7@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Comment (by Phyx-): @simonmar, Sure I'd be happy to do that bit. I should be finished with my current linker changes end of next week and will start on this then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 11:12:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 11:12:43 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.7568f20dbafa2cb2e75e63afa7349663@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 6.8.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 alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 13:12:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 13:12:20 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.92efc91f161ada67dd641d1ef99927e8@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.1 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): Simon, may I ask why you're inclined to think that it'd be better to do CSE earlier not later? Is it because of type safety reasons? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 13:28:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 13:28:36 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker Message-ID: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Playing with `-fsplit-sections` on Windows I've found a pile of ancient (it was borrowed from Hugs interpreter code and I don't even know when was it created), absolutely redundant and plain wrong code in RTS linker. Technically it is a bug, but it doesn't break things when used with current Windows binutils with no special linker scripts involved. OTOH, it slows down runtime linker on Windows noticeably and thus can be considered as a performance bug. I've attached the patch which fixes this. The nice side-effect for existing users is that GHCi now loads compiled object code much faster on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 13:28:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 13:28:57 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.e8d8fb9aa537fc1a70e1e481d58779b5@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * Attachment "ghc-rts-linker-pe-handling.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 13:29:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 13:29:48 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.5947e619c3b012ec1a8797f362ab89c4@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 13:48:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 13:48:21 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.a11ae55145f6b33de3ef389d40967acf@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 15:30:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 15:30:27 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.75a4644ab0a1e6fc0a075e585cd4abc5@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1753 Wiki Page: | ----------------------------------+---------------------------------- Changes (by Phyx-): * differential: => Phab:D1753 Comment: Fix the output on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:34:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:34:29 -0000 Subject: [GHC] #10337: One-shot module loops have hard to understand messages In-Reply-To: <045.38e47b01e257bb3e34f7bb0cb6f9d348@haskell.org> References: <045.38e47b01e257bb3e34f7bb0cb6f9d348@haskell.org> Message-ID: <060.f0772f37e2417fd0b62b0b5d7fff5cb8@haskell.org> #10337: One-shot module loops have hard to understand messages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 osa1): * cc: osa1 (added) Comment: +1 this is very annoying. This happens when working on GHC too. For example, add {{{import StgSyn}}} in {{{TrieMap}}} and you get this completely unhelpful error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:38:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:38:21 -0000 Subject: [GHC] #11389: Print a message when loading a .ghci file Message-ID: <047.1d63cb35ff6f4d0a115e374b02190353@haskell.org> #11389: Print a message when loading a .ghci file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 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'd be nice to have a notice displayed when ghci loads a .ghci file, something like {{{ rwbarton at morphism:~$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rwbarton/.ghci Prelude> }}} I want this mostly so that we can tell whether people filing ghci bugs might have anything relevant in their `.ghci` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:48:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:48:16 -0000 Subject: [GHC] #10337: One-shot module loops have hard to understand messages In-Reply-To: <045.38e47b01e257bb3e34f7bb0cb6f9d348@haskell.org> References: <045.38e47b01e257bb3e34f7bb0cb6f9d348@haskell.org> Message-ID: <060.2869cf943a3bb7d77d2990a69ecb639a@haskell.org> #10337: One-shot module loops have hard to understand messages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 osa1): Actually, I think there's something else going wrong about this in GHC HEAD: {{{ ? circular ghc-stage1 --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160108 ? circular cat A.hs module A where -- import B ? circular cat B.hs module B where import A ? circular ghc-stage1 --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) ? circular cat A.hs module A where import B ? circular ghc-stage1 -c A.hs ? circular }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:54:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:54:07 -0000 Subject: [GHC] #11390: GHC does not warn about redundant equations Message-ID: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> #11390: GHC does not warn about redundant equations -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: warnings | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- type-families/ What are type families?] would fare: {{{ % ghci -Wall -XTypeFamilies -ignore-dot-ghci GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help Prelude> :set +m Prelude> type family F1 a where Prelude| F1 Int = Bool Prelude| Prelude> let Prelude| sillyId :: F1 Char -> F1 Char Prelude| sillyId x = x Prelude| Prelude> }}} This seems to fly, even though as the blog post noted, ?[...] sillyId can?t ever be called on a value.? Isn't the clause redundant and should be defined using `EmptyCase` (#2431) as `sillyId x = case x of {}`? It seems GHC doesn't care that the pattern match in the equation `absurd2 _ = ...` is redundant either: {{{#!hs data Void absurd1 :: Void -> a; absurd1 = \case absurd2 :: Void -> a absurd2 _ = undefined }}} Is this intended or known behaviour? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:54:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:54:22 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns (was: GHC does not warn about redundant equations) In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.13230ee0b4e008d7df371423c24158d2@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 Sat Jan 9 16:54:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:54:59 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.94cda3417f3d761ab7a21e9cb7f104f8@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 Iceland_jack: Old description: > Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from > Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- > type-families/ What are type families?] would fare: > > {{{ > % ghci -Wall -XTypeFamilies -ignore-dot-ghci > GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help > Prelude> :set +m > Prelude> type family F1 a where > Prelude| F1 Int = Bool > Prelude| > Prelude> let > Prelude| sillyId :: F1 Char -> F1 Char > Prelude| sillyId x = x > Prelude| > Prelude> > }}} > > This seems to fly, even though as the blog post noted, ?[...] sillyId > can?t ever be called on a value.? Isn't the clause redundant and should > be defined using `EmptyCase` (#2431) as `sillyId x = case x of {}`? > > It seems GHC doesn't care that the pattern match in the equation `absurd2 > _ = ...` is redundant either: > {{{#!hs > data Void > > absurd1 :: Void -> a; > absurd1 = \case > > absurd2 :: Void -> a > absurd2 _ = undefined > }}} > > Is this intended or known behaviour? New description: Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- type-families/ What are type families?] would fare: {{{ % ghci -Wall -XTypeFamilies -ignore-dot-ghci GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help Prelude> :set +m Prelude> type family F1 a where Prelude| F1 Int = Bool Prelude| Prelude> let Prelude| sillyId :: F1 Char -> F1 Char Prelude| sillyId x = x Prelude| Prelude> }}} This seems to fly, even though as the blog post noted, ?[...] sillyId can?t ever be called on a value.? Isn't the clause redundant and should be defined using `EmptyCase` (#2431) as `sillyId x = case x of {}`? It seems GHC doesn't care that the pattern match in the equation `absurd2 _ = ...` is redundant either: {{{#!hs data Void absurd1 :: Void -> a absurd1 = \case absurd2 :: Void -> a absurd2 _ = undefined }}} Is this intended or known behaviour? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:57:56 -0000 Subject: [GHC] #11391: TypeError is fragile Message-ID: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | 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: -------------------------------------+------------------------------------- Consider this use of the new `TypeError` feature, {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, UndecidableInstances #-} {-# LANGUAGE UndecidableInstances #-} import Data.Kind import GHC.TypeLits (TypeError, ErrorMessage(..)) type family Resolve (t :: Type -> Type) :: Type -> Type where Resolve _ = TypeError (Text "ERROR") }}} ==== The okay case ==== Given something like, {{{#!hs testOK :: Resolve [] Int testOK = [] }}} we find that things work as expected, {{{ ? ERROR ? In the expression: [] :: Resolve [] Int In an equation for ?testOK?: testOK = [] :: Resolve [] Int }}} This is what we would expect. ==== The bad case ==== However, it is very easy to fool GHC into not yielding the desired error message. For instance, {{{#!hs testNOTOK1 :: Resolve [] Int testNOTOK1 = () }}} gives us this a unification error, {{{ ? Couldn't match type ?()? with ?(TypeError ...)? Expected type: Resolve [] Int Actual type: () }}} This clearly isn't what we expected. ==== The tricky case ==== Another way we can fool the typechecker is to make it attempt instance resolution on our `TypeError`, {{{#!hs testNOTOK2 :: Resolve [] Int testNOTOK2 = 1 }}} Which results in, {{{ ? No instance for (Num (TypeError ...)) arising from the literal ?1? ? In the expression: 1 In an equation for ?testNOTOK2?: testNOTOK2 = 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:58:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:58:54 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.a335a594743d6e8da828b62a6b4eb014@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Consider this use of the new `TypeError` feature, > {{{#!hs > {-# LANGUAGE TypeInType, TypeFamilies, UndecidableInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > import Data.Kind > import GHC.TypeLits (TypeError, ErrorMessage(..)) > > type family Resolve (t :: Type -> Type) :: Type -> Type where > Resolve _ = TypeError (Text "ERROR") > }}} > > ==== The okay case ==== > > Given something like, > {{{#!hs > testOK :: Resolve [] Int > testOK = [] > }}} > we find that things work as expected, > {{{ > ? ERROR > ? In the expression: [] :: Resolve [] Int > In an equation for ?testOK?: testOK = [] :: Resolve [] Int > }}} > This is what we would expect. > > ==== The bad case ==== > > However, it is very easy to fool GHC into not yielding the desired error > message. For instance, > {{{#!hs > testNOTOK1 :: Resolve [] Int > testNOTOK1 = () > }}} > gives us this a unification error, > {{{ > ? Couldn't match type ?()? with ?(TypeError ...)? > Expected type: Resolve [] Int > Actual type: () > }}} > This clearly isn't what we expected. > > ==== The tricky case ==== > > Another way we can fool the typechecker is to make it attempt instance > resolution on our `TypeError`, > {{{#!hs > testNOTOK2 :: Resolve [] Int > testNOTOK2 = 1 > }}} > Which results in, > {{{ > ? No instance for (Num (TypeError ...)) > arising from the literal ?1? > ? In the expression: 1 > In an equation for ?testNOTOK2?: testNOTOK2 = 1 > }}} New description: Consider this use of the new `TypeError` feature, {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, UndecidableInstances #-} {-# LANGUAGE UndecidableInstances #-} import Data.Kind import GHC.TypeLits (TypeError, ErrorMessage(..)) type family Resolve (t :: Type -> Type) :: Type -> Type where Resolve _ = TypeError (Text "ERROR") }}} ==== The okay case ==== Given something like, {{{#!hs testOK :: Resolve [] Int testOK = [] }}} we find that things work as expected, {{{ ? ERROR ? In the expression: [] :: Resolve [] Int In an equation for ?testOK?: testOK = [] :: Resolve [] Int }}} ==== The bad case ==== However, it is very easy to fool GHC into not yielding the desired error message. For instance, {{{#!hs testNOTOK1 :: Resolve [] Int testNOTOK1 = () }}} gives us this a unification error, {{{ ? Couldn't match type ?()? with ?(TypeError ...)? Expected type: Resolve [] Int Actual type: () }}} This clearly isn't what we expected. ==== The tricky case ==== Another way we can fool the typechecker is to make it attempt instance resolution on our `TypeError`, {{{#!hs testNOTOK2 :: Resolve [] Int testNOTOK2 = 1 }}} Which results in, {{{ ? No instance for (Num (TypeError ...)) arising from the literal ?1? ? In the expression: 1 In an equation for ?testNOTOK2?: testNOTOK2 = 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:59:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:59:05 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.5b87e1a7729f8600d04eddedaf3eaa26@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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 bgamari): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 16:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 16:59:21 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.445a1dd526f75ae0cc13c9804e9c47c8@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #9637 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:09:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:09:07 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.b7bdf83c9b8e72985e815e51b226e1fc@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 rwbarton): Empty data declarations are Haskell 2010, so it doesn't seem reasonable to give a warning that suggests something outside the Haskell 2010 language. If EmptyCase is already on, though, it could make sense to issue a warning in your second example. I don't understand your first example. Isn't the clause `sillyId x = case x of {}` just as "redundant" as the clause `sillyId x = x` was in the first place? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:12:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:12:58 -0000 Subject: [GHC] #11392: Decide and document how semicolons are supposed to work in GHCi Message-ID: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> #11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10663 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there is a fair bit of confusion surrounding the intended function of semicolons in GHCi (see #10663 and Phab:D1726), * the users guide doesn't discuss the matter at all * sometimes the content after semicolons work as expected {{{ ?> let x=2; y=5 ?> x+y 7 }}} * other times it is silently ignored (see #10663), {{{ ?> import Data.List; 684 ?> }}} * other times it works but the parser state is subtly wrong, resulting in (arguably) incorrect line numbers later in the session, {{{ ?> data Infix a b = a :@: b; infixl 4 :@: ?> a :3:1: error: Variable not in scope: a }}} * some times the only way to accomplish a given task is with a semicolon, {{{ Prelude> data Infix a b = a :@: b; infixl 4 :@: -- this is OK, but: Prelude> data Infix a b = a :@: b Prelude> infixl 4 :@: :12:10: error: The fixity signature for `:@:' lacks an accompanying binding (The fixity signature must be given where `:@:' is declared) }}} This inconsistency is surprising and at times frustrating. Let's decide how we want semicolons to work and stick with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:13:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:13:14 -0000 Subject: [GHC] #11392: Decide and document how semicolons are supposed to work in GHCi In-Reply-To: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> References: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> Message-ID: <061.4239ad9546f56140416d7d6ac3a938e8@haskell.org> #11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | 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: #10663 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: rdragon (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:13:42 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.630cfdeed796abd87b0b125b9983ce8c@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 Iceland_jack): I thought `case x of {}` indicated to the compiler that the clause is empty ([http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#empty-case-alternatives Empty case alternative]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:15:02 -0000 Subject: [GHC] #10663: ghci ignores stuff after an import command and a semicolon In-Reply-To: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> References: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> Message-ID: <062.25fcebf3293c609d3ee321c50b55b124@haskell.org> #10663: ghci ignores stuff after an import command and a semicolon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer 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:D1726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a84c21ebaa5c56a222d69f245ef4daa77054fdcb/ghc" a84c21eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a84c21ebaa5c56a222d69f245ef4daa77054fdcb" Reject import declaration with semicolon in GHCi Now GHCi rejects input containing an import declaration and semicolon, and prints an appropriate error message. Before, the stuff after an import declaration and semicolon got ignored (most of the time), without telling the user about it. As the default behaviour of GHCi is to reject multiple commands in a single input, we extend this behaviour to import commands. This patch fixes #10663. (See https://phabricator.haskell.org/D1518 for the introduction of `is_import` and `is_decl`.) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1726 GHC Trac Issues: #10663 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:17:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:17:50 -0000 Subject: [GHC] #10663: ghci ignores stuff after an import command and a semicolon In-Reply-To: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> References: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> Message-ID: <062.1da1e62ee29e4abd931c2696319afb46@haskell.org> #10663: ghci ignores stuff after an import command and a semicolon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer 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:D1726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:20:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:20:12 -0000 Subject: [GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 In-Reply-To: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> References: <050.46bbec1a08673e470b59ca51c3302df6@haskell.org> Message-ID: <065.88ace15eeee9a7aaf0c7ac1a396bf66f@haskell.org> #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Generics 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:D1740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:20:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:20:41 -0000 Subject: [GHC] #11341: Reifying a GADT doesn't tell you the correct return type In-Reply-To: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> References: <050.a5aa2b10b219d59596bc2e5d373019d3@haskell.org> Message-ID: <065.7c465de831c542c12bf21ff692286c66@haskell.org> #11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T11341 Blocked By: | Blocking: Related Tickets: #10828 #10719 | Differential Rev(s): Phab:D1738 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:22:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:22:44 -0000 Subject: [GHC] #11304: Programs compiled with GHC master segfault when run with +RTS -h In-Reply-To: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> References: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> Message-ID: <061.81047b5b2c09a965a3fcbc2d9cba4e34@haskell.org> #11304: Programs compiled with GHC master segfault when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:23:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:23:22 -0000 Subject: [GHC] #11304: Programs compiled with GHC master segfault when run with +RTS -h In-Reply-To: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> References: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> Message-ID: <061.f7b1be5400b04560bd0d001b90c2ada0@haskell.org> #11304: Programs compiled with GHC master segfault when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged in d699446a50f92005a8b6515633a3c8937962e225. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:23:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:23:56 -0000 Subject: [GHC] #11268: Extend ghc environment file features In-Reply-To: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> References: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> Message-ID: <057.05a4f1e940cadb0a05d07a6a7444effe@haskell.org> #11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: duncan Type: feature request | Status: closed Priority: highest | Milestone: 8.0.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:D1668 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: In both `ghc-8.0` and `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:26:15 -0000 Subject: [GHC] #11308: haddock and Cabal regression In-Reply-To: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> References: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> Message-ID: <060.505681b856c5ff7c75371b67d3b24287@haskell.org> #11308: haddock and Cabal regression -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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: upstream => closed * resolution: => fixed Comment: This has been fixed in both `master` and `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:27:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:27:42 -0000 Subject: [GHC] #11386: Improve error message In-Reply-To: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> References: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> Message-ID: <066.220184d095019c2ad2d18848e501412e@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10362 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * failure: None/Unknown => Incorrect warning at compile-time * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:28:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:28:25 -0000 Subject: [GHC] #11314: Documentation on const function is wrong In-Reply-To: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> References: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> Message-ID: <066.d1e37f7437ea739e23ffe863f1961c1b@haskell.org> #11314: Documentation on const function is wrong -------------------------------------+------------------------------------- Reporter: milleniumbug | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.3 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:D1720 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:30:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:30:00 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.eb73c92e83eaf5a0eadc91a05b873ec1@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11276, #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11302 => #11276, #11302 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:30:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:30:33 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.37250de038140e145181181bb7620ce9@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: The warning is now disabled by default. There are still, however, performance issues in the pattern checker in the presence of guards. See #11163 and #11276. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:30:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:30:49 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.b505e0e8d62d9cae29e0c100c497372a@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11163, #11276 | Differential Rev(s): Phab:D1737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11163, #11276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:30:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:30:59 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.8fe79ad3e4dc70a5ea1b08b097b4c711@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11163, #11276 | Differential Rev(s): Phab:D1737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:31:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:31:40 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis In-Reply-To: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> References: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> Message-ID: <061.8f87839602223c68b5f33f6cb5057ae3@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: #7669 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: duplicate => Comment: This was closed through a chain of duplicates leading to #595, but the new pattern exhaustiveness checker in 8.0 still exhibits the issue described in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:32:06 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.4ac96b1cd83336217d923eaf0be5953f@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): D1739 is currently blocked on goldfire, since we would like to unwire `error` and `undefined` to simplify this whole mess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:33:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:33:01 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.31d2d806b3d133c95954112a9853b1c8@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:34:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:34:55 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.2dd50cb6471a7b7dbae139e69ed69542@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.6.3 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:D1742 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:35:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:35:14 -0000 Subject: [GHC] #8793: Improve GHC.Event.IntTable performance In-Reply-To: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> References: <042.832e246164ad584bd4defd821d7fedf1@haskell.org> Message-ID: <057.0ebfa854a235de2a580b73bbfb4633c2@haskell.org> #8793: Improve GHC.Event.IntTable performance -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.6.3 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:D1742 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This has been merged into both `master` and `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:36:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:36:07 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.caa332d0110ad54d45d6d20127e876a4@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 rwbarton): I would say that `case x of {}` is just a case expression with no alternatives. It is, itself, still an ordinary expression. So both versions look like `sillyId x = ` and should be equivalent as far as redundancy of the ''outer'' pattern match, the one done by `sillyId`, is concerned. Since you cannot write a definition with 0 equations, this "redundancy" is unavoidable. (Unless you use LambdaCase and EmptyCase, I guess.) Are you suggesting treating `case x of {}` as some kind of special form? Also, I'm not sure a "stuck" type family application is really empty in the same sense as an empty data type. But #10746 makes it hard to tell what GHC thinks about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:36:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:36:21 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.65a63db587d407735c94adcaefeccb37@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | 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): Phab:D1565 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: The diff is blocked on changes so I'm going punt this out of patch state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:38:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:38:44 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.ba21dc0f4c8ab66cee5352a4e9ac30e5@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: Phyx- => * status: patch => new Comment: Punting out of patch status while the remaining issues are sorted out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:42:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:42:29 -0000 Subject: [GHC] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms In-Reply-To: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> References: <048.9dfa4d5f7d77c8b32de79bc488366aba@haskell.org> Message-ID: <063.94d7d3d5abb3c1a693ab0730ad56f020@haskell.org> #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:43:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:43:41 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.c21d4d185560649a58d95f2b71e267c0@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: pattern | checker 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: => pattern checker -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:43:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:43:49 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup In-Reply-To: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> References: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> Message-ID: <057.0fb19e4fc08c12945ae5a7133796ff65@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: pattern | checker 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: => pattern checker -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:44:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:44:13 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 In-Reply-To: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> References: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> Message-ID: <061.8326687a81a7ea7b78c2eb80b22326cf@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: pattern | checker Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => pattern checker -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:44:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:44:23 -0000 Subject: [GHC] #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) In-Reply-To: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> References: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> Message-ID: <062.02c8c3ff532a799945157a4a7a34e6fd@haskell.org> #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | matching, exhaustiveness, pattern | checker Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #595 | Differential Rev(s): Wiki Page: | PatternMatchCheck, | PatternMatchCheckImplementation | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: pattern matching, exhaustiveness => pattern matching, exhaustiveness, pattern checker -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:47:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:47:17 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.eef2aae600cf028b2e41effaec787f6f@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 Iceland_jack): I thought that was what the documentation for `EmptyCase` is alluding to: > With dependently-typed features it is more useful (see Trac #2431). For example, consider these two candidate definitions of absurd: > > {{{#!hs > data a :==: b where > Refl :: a :==: a > > absurd :: True :~: False -> a > absurd x = error "absurd" -- (A) > absurd x = case x of {} -- (B) > }}} > > We much prefer (B). Why? Because GHC can figure out that `(True :~: False)` is an empty type. So (B) has no partiality and GHC should be able to compile with [http://downloads.haskell.org/~ghc/master/users-guide /using-warnings.html#ghc-flag--Wincomplete-patterns -Wincomplete- patterns]. (Though the pattern match checking is not yet clever enough to do that.) On the other hand (A) looks dangerous, and GHC doesn?t check to make sure that, in fact, the function can never get called. I wasn't sure whether the "Though the pattern match checking is not yet clever enough to do that." statement had changed in 8, I'll edit the code to enable `LambdaCase` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:48:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:48:14 -0000 Subject: [GHC] #10663: ghci ignores stuff after an import command and a semicolon In-Reply-To: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> References: <047.73a74704a50af0b4eacdd79f94136aad@haskell.org> Message-ID: <062.1785ac672610138efb5c715d44bcfa82@haskell.org> #10663: ghci ignores stuff after an import command and a semicolon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: newcomer 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:D1726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:48:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:48:27 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.7876897e7dfc5e4d36d928b87ffd9947@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings 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 Iceland_jack: Old description: > Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from > Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- > type-families/ What are type families?] would fare: > > {{{ > % ghci -Wall -XTypeFamilies -ignore-dot-ghci > GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help > Prelude> :set +m > Prelude> type family F1 a where > Prelude| F1 Int = Bool > Prelude| > Prelude> let > Prelude| sillyId :: F1 Char -> F1 Char > Prelude| sillyId x = x > Prelude| > Prelude> > }}} > > This seems to fly, even though as the blog post noted, ?[...] sillyId > can?t ever be called on a value.? Isn't the clause redundant and should > be defined using `EmptyCase` (#2431) as `sillyId x = case x of {}`? > > It seems GHC doesn't care that the pattern match in the equation `absurd2 > _ = ...` is redundant either: > {{{#!hs > data Void > > absurd1 :: Void -> a > absurd1 = \case > > absurd2 :: Void -> a > absurd2 _ = undefined > }}} > > Is this intended or known behaviour? New description: Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- type-families/ What are type families?] would fare: {{{ % ghci -Wall -XTypeFamilies -ignore-dot-ghci GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help Prelude> :set +m Prelude> type family F1 a where Prelude| F1 Int = Bool Prelude| Prelude> let Prelude| sillyId :: F1 Char -> F1 Char Prelude| sillyId x = x Prelude| Prelude> }}} This seems to fly, even though as the blog post noted, ?[...] sillyId can?t ever be called on a value.? Isn't the clause redundant and should be defined using `EmptyCase` (#2431) as `sillyId = \case`? It seems GHC doesn't care that the pattern match in the equation `absurd2 _ = ...` is redundant either: {{{#!hs data Void absurd1 :: Void -> a absurd1 = \case absurd2 :: Void -> a absurd2 _ = undefined }}} Is this intended or known behaviour? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:48:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:48:54 -0000 Subject: [GHC] #11347: No skolem info: b_azg[sk] In-Reply-To: <046.e27f7055787d51e2a672587abfd14828@haskell.org> References: <046.e27f7055787d51e2a672587abfd14828@haskell.org> Message-ID: <061.ceedeaf4196b9c088a8b00224b11900f@haskell.org> #11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11347 Blocked By: | Blocking: Related Tickets: #10946, #10045 | Differential Rev(s): 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 Sat Jan 9 17:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:52:22 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.94b627d462beaa1bd5c115b12d8c6867@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from > Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- > type-families/ What are type families?] would fare: > > {{{ > % ghci -Wall -XTypeFamilies -ignore-dot-ghci > GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help > Prelude> :set +m > Prelude> type family F1 a where > Prelude| F1 Int = Bool > Prelude| > Prelude> let > Prelude| sillyId :: F1 Char -> F1 Char > Prelude| sillyId x = x > Prelude| > Prelude> > }}} > > This seems to fly, even though as the blog post noted, ?[...] sillyId > can?t ever be called on a value.? Isn't the clause redundant and should > be defined using `EmptyCase` (#2431) as `sillyId = \case`? > > It seems GHC doesn't care that the pattern match in the equation `absurd2 > _ = ...` is redundant either: > {{{#!hs > data Void > > absurd1 :: Void -> a > absurd1 = \case > > absurd2 :: Void -> a > absurd2 _ = undefined > }}} > > Is this intended or known behaviour? New description: Given the Phab:D1535 effort in GHC 8.0 I was curious how an example from Richard's post [https://typesandkinds.wordpress.com/2015/09/09/what-are- type-families/ What are type families?] would fare: {{{ % ghci -Wall -XTypeFamilies -ignore-dot-ghci GHCi, version 8.1.20160105: http://www.haskell.org/ghc/ :? for help Prelude> :set +m Prelude> type family F1 a where Prelude| F1 Int = Bool Prelude| Prelude> let Prelude| sillyId :: F1 Char -> F1 Char Prelude| sillyId x = x Prelude| Prelude> }}} This seems to fly, even though as the blog post noted, ?[...] sillyId can?t ever be called on a value.? Isn't the clause redundant and should be defined using `EmptyCase` (#2431) as `sillyId = \case`? It seems GHC doesn't care that the pattern match in the equation `absurd2 _ = ...` is redundant either: {{{#!hs data Void absurd1 :: Void -> a absurd1 = \case absurd2 :: Void -> a absurd2 _ = undefined }}} Is this intended or known behaviour? -- Comment (by rwbarton): The manual there is talking about partiality, or completeness of pattern matches, not redundancy. (B) is complete because the pattern match in `absurd` is complete, and the pattern match in the `case` is also complete. But the pattern match in `absurd` is "redundant", regardless of what happens on the right-hand side of the equation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 17:59:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 17:59:02 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.61975349bdde747b8853924778479564@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11356 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as d60b89b9a0f5212e35210f6e66d119ca025f7a5c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:02:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:02:48 -0000 Subject: [GHC] #11393: Ability to define INLINE pragma for all instances of a given typeclass Message-ID: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> #11393: Ability to define INLINE pragma for all instances of a given typeclass -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Hello! I would like to request a feature that would allow me to define the `INLINE` pragma for all instances of a given type class. Currently when we are creating high-performance libraries, that strongly depend on type- level computations we are using a lot of typeclasses that we want to be cut-out during the compilation time. We can use the `INLINE` pragma to be sure that after type-class resolution the code will be inlined and hopefully strongly optimized, but we have to put the pragme in every single type class instance, which makes the code look ugly and is just impractival. So I would like to transform code like (this is just example, not a real-world problem solving code): {{{ class Foo a b where foo :: a -> b instance Foo Int String where foo = show {-# INLINE foo #-} instance Foo Int Int where foo = id {-# INLINE foo #-} instance Foo Int Float where foo = fromIntegral {-# INLINE foo #-} }}} into: {{{ class Foo a b where foo :: a -> b {-# INLINE foo #-} instance Foo Int String where foo = show instance Foo Int Int where foo = id instance Foo Int Float where foo = fromIntegral }}} I think it would be pretty easy to support such syntax and a lot of libraries would benefit from the design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:04:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:04:29 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.55406b105bdc13ddf4878b6d4eacb88e@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: We likely won't make it to complete determinism for 8.0, sadly. Let's hope for 8.2! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:06:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:06:26 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.73673263c75809c6e2a5182a6874d357@haskell.org> #314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't happen for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:08:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:08:22 -0000 Subject: [GHC] #8736: GHCi doesn't load .dyn_o files appropriately In-Reply-To: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> References: <052.b282b771a49ddd09f40719b07cb558fa@haskell.org> Message-ID: <067.9388e54e70f1924178c6bb0100cc8a5e@haskell.org> #8736: GHCi doesn't load .dyn_o files appropriately -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9282 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The remote GHCi support described in #11100 has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:12:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:12:07 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.fce59b96fded4a12a9a4e8a5cf0d6fbc@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: Yet another release where this didn't happen. Due to the relatively small amount of activity on this ticket I'm going to reduce its priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:12:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:12:31 -0000 Subject: [GHC] #11393: Ability to define INLINE pragma for all instances of a given typeclass In-Reply-To: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> References: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> Message-ID: <061.cf66f9199382e8acf6b05906c0f4cd91@haskell.org> #11393: Ability to define INLINE pragma for all instances of a given typeclass -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 danilo2: Old description: > Hello! I would like to request a feature that would allow me to define > the `INLINE` pragma for all instances of a given type class. Currently > when we are creating high-performance libraries, that strongly depend on > type-level computations we are using a lot of typeclasses that we want to > be cut-out during the compilation time. We can use the `INLINE` pragma to > be sure that after type-class resolution the code will be inlined and > hopefully strongly optimized, but we have to put the pragme in every > single type class instance, which makes the code look ugly and is just > impractival. So I would like to transform code like (this is just > example, not a real-world problem solving code): > > {{{ > > class Foo a b where foo :: a -> b > > instance Foo Int String where foo = show > {-# INLINE foo #-} > instance Foo Int Int where foo = id > {-# INLINE foo #-} > instance Foo Int Float where foo = fromIntegral > {-# INLINE foo #-} > > }}} > > into: > > {{{ > > class Foo a b where foo :: a -> b > {-# INLINE foo #-} > > instance Foo Int String where foo = show > instance Foo Int Int where foo = id > instance Foo Int Float where foo = fromIntegral > > }}} > > I think it would be pretty easy to support such syntax and a lot of > libraries would benefit from the design. New description: Hello! I would like to request a feature that would allow me to define the `INLINE` pragma for all instances of a given type class. Currently when we are creating high-performance libraries, that strongly depend on type- level computations we are using a lot of typeclasses that we want to be cut-out during the compilation time. We can use the `INLINE` pragma to be sure that after type-class resolution the code will be inlined and hopefully strongly optimized, but we have to put the pragme in every single type class instance, which makes the code look ugly and is just impractival. So I would like to transform code like (this is just example, not a real-world problem solving code): {{{ class Foo a b where foo :: a -> b instance Foo Int String where foo = show {-# INLINE foo #-} instance Foo Int Int where foo = id {-# INLINE foo #-} instance Foo Int Float where foo = fromIntegral {-# INLINE foo #-} }}} into: {{{ class Foo a b where foo :: a -> b {-# INLINE foo #-} instance Foo Int String where foo = show instance Foo Int Int where foo = id instance Foo Int Float where foo = fromIntegral }}} I think it would be pretty easy to support such syntax and a lot of libraries would benefit from the design. Edit: As a small note - I've seen another way of dealing with the problem, namely mixing the pragmas with semicolons like that: {{{ class Foo a b where foo :: a -> b instance Foo Int String where foo = show ;{-# INLINE foo #-} instance Foo Int Int where foo = id ;{-# INLINE foo #-} instance Foo Int Float where foo = fromIntegral ;{-# INLINE foo #-} }}} But this is just another ugly work-around, not a nice solution. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:25:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:25:18 -0000 Subject: [GHC] #11393: Ability to define INLINE pragma for all instances of a given typeclass In-Reply-To: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> References: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> Message-ID: <061.726e9582e5c6dac5a0a125691a3cb0e7@haskell.org> #11393: Ability to define INLINE pragma for all instances of a given typeclass -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 danilo2: Old description: > Hello! I would like to request a feature that would allow me to define > the `INLINE` pragma for all instances of a given type class. Currently > when we are creating high-performance libraries, that strongly depend on > type-level computations we are using a lot of typeclasses that we want to > be cut-out during the compilation time. We can use the `INLINE` pragma to > be sure that after type-class resolution the code will be inlined and > hopefully strongly optimized, but we have to put the pragme in every > single type class instance, which makes the code look ugly and is just > impractival. So I would like to transform code like (this is just > example, not a real-world problem solving code): > > {{{ > > class Foo a b where foo :: a -> b > > instance Foo Int String where foo = show > {-# INLINE foo #-} > instance Foo Int Int where foo = id > {-# INLINE foo #-} > instance Foo Int Float where foo = fromIntegral > {-# INLINE foo #-} > > }}} > > into: > > {{{ > > class Foo a b where foo :: a -> b > {-# INLINE foo #-} > > instance Foo Int String where foo = show > instance Foo Int Int where foo = id > instance Foo Int Float where foo = fromIntegral > > }}} > > I think it would be pretty easy to support such syntax and a lot of > libraries would benefit from the design. > > Edit: As a small note - I've seen another way of dealing with the > problem, namely mixing the pragmas with semicolons like that: > > {{{ > > class Foo a b where foo :: a -> b > > instance Foo Int String where foo = show ;{-# INLINE foo #-} > instance Foo Int Int where foo = id ;{-# INLINE foo #-} > instance Foo Int Float where foo = fromIntegral ;{-# INLINE foo #-} > > }}} > > But this is just another ugly work-around, not a nice solution. New description: Hello! I would like to request a feature that would allow me to define the `INLINE` pragma for all instances of a given type class. Currently when we are creating high-performance libraries, that strongly depend on type- level computations we are using a lot of typeclasses that we want to be cut-out during the compilation time. We can use the `INLINE` pragma to be sure that after type-class resolution the code will be inlined and hopefully strongly optimized, but we have to put the pragme in every single type class instance, which makes the code look ugly and is just impractival. So I would like to transform code like (this is just example, not a real-world problem solving code): {{{ class Foo a b where foo :: a -> b instance Foo Int String where foo = show {-# INLINE foo #-} instance Foo Int Int where foo = id {-# INLINE foo #-} instance Foo Int Float where foo = fromIntegral {-# INLINE foo #-} }}} into: {{{ class Foo a b where foo :: a -> b {-# INLINE foo #-} instance Foo Int String where foo = show instance Foo Int Int where foo = id instance Foo Int Float where foo = fromIntegral }}} I think it would be pretty easy to support such syntax and a lot of libraries would benefit from the design. Unfortunatelly the proposed design does not nicely mix with default methods in classes, where we can use the pragma to denote that the default implementation should be inlined. But if there is no default method implementation GHC rejects the above example, so I think we can find a nice solution for the problem. Edit: As a small note - I've seen another way of dealing with the problem, namely mixing the pragmas with semicolons like that: {{{ class Foo a b where foo :: a -> b instance Foo Int String where foo = show ;{-# INLINE foo #-} instance Foo Int Int where foo = id ;{-# INLINE foo #-} instance Foo Int Float where foo = fromIntegral ;{-# INLINE foo #-} }}} But this is just another ugly work-around, not a nice solution. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:26:51 -0000 Subject: [GHC] #10603: Output of -ddump-splices is parenthesized incorrectly In-Reply-To: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> References: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> Message-ID: <065.5e6938c8ecccd82ed99cec487173c90a@haskell.org> #10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Rev(s): Phab:D1114 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4405f9de855bdd37117e8bdef2da550ac398d81e/ghc" 4405f9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4405f9de855bdd37117e8bdef2da550ac398d81e" Add failing testcase for #10603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:26:51 -0000 Subject: [GHC] #10603: Output of -ddump-splices is parenthesized incorrectly In-Reply-To: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> References: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> Message-ID: <065.0a3d8d82474bdace38b60d82b250db3a@haskell.org> #10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Rev(s): Phab:D1114 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5cb236dd6b497da0b9072b20ca74c298477f7a61/ghc" 5cb236d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5cb236dd6b497da0b9072b20ca74c298477f7a61" fix -ddump-splices to parenthesize ((\x -> x) a) correctly Test Plan: ./validate Reviewers: goldfire, austin, bgamari Subscribers: goldfire, osa1, thomie Differential Revision: https://phabricator.haskell.org/D1114 GHC Trac Issues: #10603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:45:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:45:22 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.812fa69cead0d73db50027cea37a2bb5@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Old description: > it was recently demonstrated on the haskell-cafe mailing list that the > following code takes measurably longer to type check in GHC 7.8.2 than in > GHC 7.6. > > http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html > > the program example is as follows > {{{ > begin :: Monad m => (m () -> t) -> t > begin cont = cont (return ()) > > a :: IO a -> (IO () -> t) -> t > a m cont = cont (m >> putStrLn "a") > > end :: t -> t > end m = m > > main = begin a a a a a a a a a a a a a a a a a a end > }}} > takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () > > each additional a doubles the time to type check the program > > {{{ > main = begin a a a a a a a a a a a a a a a a a a a a a a a a end > }}} > > takes longer than I have the patience to wait :) (so more than 5 seconds) > > the author of the email notes that a related program > > {{{ > main = id id id id id id id id id id id > id id id id id id id id id id id (return ()) > }}} > has the exponential complexity in both 7.8.2 and 7.6.2 > > This It could very well be that some of the type checker changes between > 7.8 and 7.6 enlarged the space of programs that trip up exponential worst > case behavior, but one way or another understanding *why* this happened New description: it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6. http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html the program example is as follows {{{#!hs begin :: Monad m => (m () -> t) -> t begin cont = cont (return ()) a :: IO a -> (IO () -> t) -> t a m cont = cont (m >> putStrLn "a") end :: t -> t end m = m main = begin a a a a a a a a a a a a a a a a a a end }}} takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () each additional a doubles the time to type check the program {{{#!hs main = begin a a a a a a a a a a a a a a a a a a a a a a a a end }}} takes longer than I have the patience to wait :) (so more than 5 seconds) the author of the email notes that a related program {{{#!hs main = id id id id id id id id id id id id id id id id id id id id id id (return ()) }}} has the exponential complexity in both 7.8.2 and 7.6.2 This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened -- Comment: This won't be fixed for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:48:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:48:54 -0000 Subject: [GHC] #10603: Output of -ddump-splices is parenthesized incorrectly In-Reply-To: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> References: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> Message-ID: <065.709e76281a274067ffb37ade302d7a54@haskell.org> #10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Rev(s): Phab:D1114 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 18:49:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 18:49:55 -0000 Subject: [GHC] #10703: -fth-dec-file can't handle lambdas In-Reply-To: <045.c081efcc1d355b132984e54043eabc1d@haskell.org> References: <045.c081efcc1d355b132984e54043eabc1d@haskell.org> Message-ID: <060.5a955c3c5257060388f0a997ac0635db@haskell.org> #10703: -fth-dec-file can't handle lambdas -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10701 #10603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This should be fixed along with #10603. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:07:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:07:15 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.6519888572057354496ef49f06d090e5@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.0.1 Comment: I'm going to set the milestone to 8.0.1, since this affects the upcoming GHC 8.0 and I'd hate to see so much `Typeable`-related code break. Please change the milestone if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:08:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:08:36 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.bbe2f6958b614a3ea3ebc98078be1b8f@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (CodeGen) | Keywords: Generics, Resolution: | 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): * milestone: => 8.0.1 Comment: I'm going to set the milestone to 8.0.1, since this affects the upcoming GHC 8.0 and it breaks a fair bit of `Generics`-related code in the wild. Please change the milestone if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:18:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:18:56 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.475a6cb8f5be3c3fb5a3b93028559709@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): My guess is that we'd want to do something like this to ensure that `System` names never make it to the user. {{{#!patch diff --git a/compiler/main/InteractiveEval.hs b/compiler/main/InteractiveEval.hs index 013be3c..d3020d7 100644 --- a/compiler/main/InteractiveEval.hs +++ b/compiler/main/InteractiveEval.hs @@ -235,8 +235,9 @@ runStmtWithLocation source linenumber expr step = do runDecls :: GhcMonad m => String -> m [Name] runDecls = runDeclsWithLocation "" 1 -runDeclsWithLocation - :: GhcMonad m => String -> Int -> String -> m [Name] +-- | Run some declarations and return any user-visible names that were brought +-- into scope. +runDeclsWithLocation :: GhcMonad m => String -> Int -> String -> m [Name] runDeclsWithLocation source linenumber expr = do hsc_env <- getSession @@ -246,7 +247,13 @@ runDeclsWithLocation source linenumber expr = hsc_env <- getSession hsc_env' <- liftIO $ rttiEnvironment hsc_env modifySession (\_ -> hsc_env') - return (map getName tyThings) + + -- Trac #11051: We filter out system names since the user is not interested + -- in them. These include, + -- * Data family tycons from, e.g., derived Generic instances + -- * Type representation (Typeable) definitions (e.g. $trMyModule) + -- * others + return $ filter (not . isSystemName) $ map getName tyThings }}} With this we've reduced the problem to ensuring that the generated Typeable identifiers get marked as `System` names. Currently they are conjured by up `IfaceEnv.newGlobalBinder` which only knows how to produce `External` names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:18:59 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.15130c6b0050c3bcf57afb52d4927ab5@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I dug a little more into the issue, and it looks like the issue is specifically with `typeOf`, not, say, `typeRep`. Compare: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160108: http://www.haskell.org/ghc/ :? for help ?> :set -XDataKinds ?> :m Data.Proxy Data.Functor.Compose Data.Typeable ?> typeRep (Proxy :: Proxy 'Compose) 'Compose ?> typeRep (Proxy :: Proxy 'Just) 'Just ?> typeRep (Proxy :: Proxy 'Proxy) 'Proxy }}} versus {{{ ?> typeOf (Proxy :: Proxy 'Compose) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160108 for x86_64-unknown-linux): piResultTy * TYPE 'Lifted * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ?> typeOf (Proxy :: Proxy 'Just) Proxy (TYPE 'Lifted -> Maybe (TYPE 'Lifted)) 'Just ?> typeOf (Proxy :: Proxy 'Proxy) Proxy (Proxy (TYPE 'Lifted) (TYPE 'Lifted)) 'Proxy }}} Those last two results definitely look funny. I'm guessing that the issue pertains to levity polymorphism. I'll try to see what I can find about how `typeOf` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:29:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:29:04 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.3a29b99710051f7c71303c0a14ccfde7@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): One of the reasons this seems to be so tricky is that `NameSort` conflates a few concerns, * Is the name given to us by the user or provided by the compiler (e.g. `WiredIn`)? * Is the name usable outside of the current module (`External` and `Internal`)? * Should the name be shown to the user (e.g. `System`)? It's not entirely clear to me when this various constructors are being used to represent what points in this space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:51:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:51:33 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows Message-ID: <046.3c711b381d30e89343445554e3990623@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.3 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: -------------------------------------+------------------------------------- There are a variety of issues caused by the impedance mismatch between GHC's use of Posix I/O interfaces on Windows (particularly with respect to console I/O), * #10542: Incorrect Unicode input on Windows Console * #7593: Unable to print exceptions of unicode identifiers * #4471: Incorrect Unicode output on Windows Console * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows As pointed on in ticket:2189#comment:12 the ultimate solution to this would be to move all of GHC's IO to use the respective Win32 interfaces. = Also relevant = * #7353: Windows lacks support in the I/O manager * #806: hGetBufNonBlocking doesn't work on Windows * #3081: Double output after Ctrl+C on Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:52:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:52:52 -0000 Subject: [GHC] #10542: Incorrect Unicode input on Windows Console In-Reply-To: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> References: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> Message-ID: <060.87b5efcd9c4bbf4d945f8e4ddc57d981@haskell.org> #10542: Incorrect Unicode input on Windows Console -------------------------------------+------------------------------------- Reporter: ptroev | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: windows stdin | utf-8 cmd chcp 65001 getLine Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11394, #4471 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: 4471 => #11394, #4471 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:53:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:53:39 -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.0425864c6266c122725b16946e98fbd5@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 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 bgamari): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:53:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:53:47 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.ab2be8370cb26e956d26fb980fb4ab15@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:54:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:54:18 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.76f7046cfd7bceabc1d8e405b99a19d5@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11394 Old description: > The following program repeats inputted characters until the escape key is > pressed. > > {{{ > import IO > import Monad > import Char > > main :: IO () > main = do hSetBuffering stdin NoBuffering > inputLoop > > inputLoop :: IO () > inputLoop = do i <- getContents > mapM_ putChar $ takeWhile ((/= 27) . ord) i > }}} > > Because of the "hSetBuffering stdin NoBuffering" line it should not be > necessary to press the enter key between keystrokes. This program works > correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not > repeat the characters until the enter key is pressed. The problem was > reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), > using both cmd.exe and command.com on Windows XP Professional. New description: The following program repeats inputted characters until the escape key is pressed. {{{#!hs import IO import Monad import Char main :: IO () main = do hSetBuffering stdin NoBuffering inputLoop inputLoop :: IO () inputLoop = do i <- getContents mapM_ putChar $ takeWhile ((/= 27) . ord) i }}} Because of the `hSetBuffering stdin NoBuffering` line it should not be necessary to press the enter key between keystrokes. This program works correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not repeat the characters until the enter key is pressed. The problem was reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), using both cmd.exe and command.com on Windows XP Professional. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:58:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:58:00 -0000 Subject: [GHC] #11381: Put injective type families in a separate language extension In-Reply-To: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> References: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> Message-ID: <063.bb992246552b7870482d6c147671fb3c@haskell.org> #11381: Put injective type families in a separate language extension -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeFamilies, | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T11381 Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1750 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fbd6de2f0761b63a5f0a88ce0590f515d63790a4/ghc" fbd6de2f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fbd6de2f0761b63a5f0a88ce0590f515d63790a4" Add InjectiveTypeFamilies language extension Previously injective type families were part of TypeFamilies. Now they are in a separate language extension. Test Plan: ./validate Reviewers: austin, bgamari, goldfire Reviewed By: bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1750 GHC Trac Issues: #11381 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 19:58:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 19:58:38 -0000 Subject: [GHC] #11381: Put injective type families in a separate language extension In-Reply-To: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> References: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> Message-ID: <063.51073cd8eb6486bc41787f92b7b9461a@haskell.org> #11381: Put injective type families in a separate language extension -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: TypeFamilies, | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T11381 Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1750 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `master` and `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 20:32:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 20:32:18 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.4d4f02b306715eee15be528e63d991da@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 20:52:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 20:52:10 -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.e613844c2718d43fa80d1688260d2fe0@haskell.org> #11389: Print a message when loading a .ghci file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kseo Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 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 kseo): * owner: => kseo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 21:07:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 21:07:10 -0000 Subject: [GHC] Batch modify: #5840, #5369, #5470, #5702, #5807, #6004, #7330, ... Message-ID: <20160109210710.9E1D43A2FF@ghc.haskell.org> Batch modification to #5840, #5369, #5470, #5702, #5807, #6004, #7330, #3782, #3903, #4831, #5646, #3960 by bgamari: milestone to ? Comment: Moving DPH tickets out to _|_ as the project is more or less stagnant. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 21:08:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 21:08:06 -0000 Subject: [GHC] #4105: ffi005 fails on OS X In-Reply-To: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> References: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> Message-ID: <059.8fdbfb2217eff5439cbd42afc06d4c7e@haskell.org> #4105: ffi005 fails on OS X -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ffi/should_run/ffi005 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Is this still the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 21:13:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 21:13:48 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.cb537fd0b0484c851b85caa464fee448@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.11 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => fixed Comment: Closing since a release was released a few weeks ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 21:14:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 21:14:55 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.54064b1383dd0af09f60be4e270b425c@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Is still an issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 22:06:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 22:06:11 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.c9cb0755582b245d7ef0590da79cdabd@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Yes it is. Just tested it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 22:13:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 22:13:25 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.b61aa92b0781c8cfa5e6237f636eaacc@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Having a look now. Might have a fix for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 22:18:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 22:18:04 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.85f24e614cdc72b3a49de5a8f4d3cf0b@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 22:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 22:58:39 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.d81948254f4750f2f6f6ac199e3b926f@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D1757 Comment: I still haven't figured out what's going on with `typeOf (Proxy :: Proxy 'Compose)`, but we can at least be comforted by the fact that executing it wasn't possible before GHC 8.0, since `Compose` is poly-kinded. The "regression" here is that `*` now shows up as `TYPE 'Lifted`, which I don't think is desirable. I've opened Phab:D1757 to fix that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 23:13:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 23:13:36 -0000 Subject: [GHC] #4105: ffi005 fails on OS X In-Reply-To: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> References: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> Message-ID: <059.81019ca6c15c1a5efe6e7251a10182e4@haskell.org> #4105: ffi005 fails on OS X -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ffi/should_run/ffi005 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kseo): ffi005 passes on my OS X with the current HEAD (fbd6de2f0761b63a5f0a88ce0590f515d63790a4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 23:33:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 23:33:49 -0000 Subject: [GHC] #4105: ffi005 fails on OS X In-Reply-To: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> References: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> Message-ID: <059.efea2649d7568825c985577be4fd7dd6@haskell.org> #4105: ffi005 fails on OS X -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ffi/should_run/ffi005 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Did you test on x86, as it says in the description? The following two commits are relevant. The first one changes the test to only run for `WAY=optc` on x86. The second deletes `WAY=optc`. So now the test is always skipped on x86. That doesn't mean the problem is solved though! * commit 05a2f49caba62723992a03676f6df6085aa514c7 {{{ Author: Simon Marlow Date: Tue Nov 24 10:14:34 2009 +0000 ffi005: run only the via-C way on x86 platforms due to 80-bit vs. 64-bit precision leading to floating point differences when using the native code generator. -fvia-C uses the -ffloat-store gcc sledgehammer to avoid this. }}} * commit dc34ea9fd80f493e00062c276b2c7c898505bca2 {{{ Author: Max Bolingbroke Date: Sat Apr 2 11:25:01 2011 +0100 Remove any mention of optc/profc from all.T files }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 9 23:42:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jan 2016 23:42:59 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) Message-ID: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) -------------------------------------+------------------------------------- Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: m68k | Type of failure: GHC doesn't work | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc is generating C code like in the following simplified example: demo1.c: {{{ #include extern void* int_returning_function(); typedef int (*int_f_ptr)(); int main(void) { int result; { int_f_ptr correctly_typed_pointer; correctly_typed_pointer = (int_f_ptr)int_returning_function; result = correctly_typed_pointer(); } assert(result == 42); return 0; } }}} demo2.c: {{{ int int_returning_function() { return 42; } }}} This code fails to work on m68k with gcc-5.3.1 if optimization is turned on. The real-life example from ghc is rts/Schedule.c:raiseExceptionHelper as int_returning_function and rts/Exception.cmm:stg_raisezh as main. The reason it fails is that on m68k, a function returning a pointer returns the result in %a0, while a function returning an integer returns it in %d0. If optimization is enabled, gcc elides the function pointer and calls the function as-if it were called directly. Without optimization, gcc expects the result to be in %d0, where it actually is. In my oppinion, gcc is allowed to do that, because according to N843 (C99 draft), 6.2.7 #2 "All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined." is violated in this example. Compatibility of return types is defined in 6.7.5.3 #11 "For two function types to be compatible, both shall specify compatible return types. Moreover, [...]" which is clearly violated. If you just look at demo1.c and assume that 6.2.7 #2 is *not* violated, int_returning_function would in fact be a function returning a pointer. In that case, compiling demo1.c would violate 6.3.2.3 #8 "If a converted pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined." and/or 6.5.2.2 "If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined." You might want to discuss this issue with the gcc developers, but I don't see a standard claus justifying the approach of declaring all functions returning StgFunPtr and casting them to the right type. If you cross-compile the source tarball Debian claims to be 7.10.3-rc1 to m68k using gcc 5.3.1, ghc crashes on startup because stg_raisezh gets a wrong value as frame_type and tries to cancel an STM transaction that does not exist at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 01:01:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 01:01:33 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.5caa0807ca352ae3af120a18891ef05c@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): Thanks, Simon. I'm afraid this won't be very helpful but I've pushed a branch of my library which exhibits the error here (I'll keep this around while this issue is open), at commit 18b99b6: https://github.com/jberryman/unagi-bloomfilter/tree/simplifier-ticks- exhausted-bug-11263 It includes frozen dependency versions. You can trigger the bug with: `cabal configure -fdev && cabal build`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 03:54:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 03:54:26 -0000 Subject: [GHC] #4105: ffi005 fails on OS X In-Reply-To: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> References: <044.92fdd8e1939b5ade063715e75597ff6d@haskell.org> Message-ID: <059.b6b56b59fedb1b0960e4f86814dfb7c1@haskell.org> #4105: ffi005 fails on OS X -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ffi/should_run/ffi005 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kseo): Replying to [comment:12 thomie]: > Did you test on x86, as it says in the description? I ran in on x64. Sorry for the confusion! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 08:59:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 08:59:47 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.b0b8aa7e546492f45d97758f2e9132dc@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"b1c063b47a6a4d078626f9a2d4b07cbb244de340/ghc" b1c063b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b1c063b47a6a4d078626f9a2d4b07cbb244de340" ghc.mk: Use Windows_Target instead of Windows_Host This is a step towards building a Linux to Windows cross-compiler. Test Plan: Build on Linux and Windows Reviewers: bgamari, hvr, austin, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1758 GHC Trac Issues: #10070 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 09:00:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 09:00:45 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.018ea280adf9ad65eac1a6f62196a3ea@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 11:46:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 11:46:04 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" Message-ID: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 IfThenElseIx.hs {-# LANGUAGE RebindableSyntax #-} module IfThenElseIx where import Data.Ix (Ix, ) import Prelude ifThenElse :: Bool -> a -> a -> a ifThenElse True x _ = x ifThenElse False _ x = x data T = A | B deriving (Eq, Ord, Ix) $ ghci-8.0.0.20160109 IfThenElseIx.hs GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling IfThenElseIx ( IfThenElseIx.hs, interpreted ) IfThenElseIx.hs:13:35: error: ? Bad call to tagToEnum# at type a_a2ky Specify the type by giving a type signature e.g. (tagToEnum# x) :: Bool ? In the second argument of ?ifThenElse?, namely ?(GHC.Prim.tagToEnum# (c# GHC.Prim.<=# b#))? In the expression: if (GHC.Prim.tagToEnum# (c# GHC.Prim.>=# a#)) then (GHC.Prim.tagToEnum# (c# GHC.Prim.<=# b#)) else False In a case alternative: c# -> if (GHC.Prim.tagToEnum# (c# GHC.Prim.>=# a#)) then (GHC.Prim.tagToEnum# (c# GHC.Prim.<=# b#)) else False When typechecking the code for ?GHC.Arr.inRange? in a derived instance for ?Ix T?: To see the code I am typechecking, use -ddump-deriv Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 11:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 11:47:20 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.b855cbc2a1c4870ed844866597d6bd71@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => parser/should_compile/VtaParse typecheck/should_compile/Vta1 typecheck/should_compile/Vta2 * priority: normal => high Comment: Panic's are bad, raising priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 11:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 11:48:56 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.495226fd9239d684d24bedcbceb1cb41@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * testcase: => dependent/should_compile/dynamic-paper Comment: Core lint errors are bad, raising priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:07:47 -0000 Subject: [GHC] #11333: GHCi does not discharge satisfied constraints In-Reply-To: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> References: <051.3795e83a0b8f73c46509bda1b8f53594@haskell.org> Message-ID: <066.7cadd8a60f4f55ae8056184405b0b943@haskell.org> #11333: GHCi does not discharge satisfied constraints ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeApplications Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * cc: goldfire (added) * keywords: => TypeApplications * version: 8.1 => 8.0.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:15:02 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.235d14a6668018c79a3aa3ef5054004c@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 8.1 => 8.0.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:27:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:27:44 -0000 Subject: [GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat In-Reply-To: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> References: <048.67491201a04ddd5c5f8addf4fce96596@haskell.org> Message-ID: <063.03f28aea82c239cbd3719ff33447c7a7@haskell.org> #10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11342 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #11342 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:28:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:28:11 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.dbb36836d95493814940ad7a62bc97e5@haskell.org> #11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10776 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * keywords: => DataKinds * related: => #10776 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:36:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:36:46 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.ef8c111c276082e26a2746fadc9afc1b@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 Comment: I guess this should go into 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:41:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:41:33 -0000 Subject: [GHC] #11346: GHCi can crash when tabbing a filename In-Reply-To: <045.bea937f4240737f03707082c605dbcc2@haskell.org> References: <045.bea937f4240737f03707082c605dbcc2@haskell.org> Message-ID: <060.175dc645cb69af18f4b510d8410f00ec@haskell.org> #11346: GHCi can crash when tabbing a filename ----------------------------------+---------------------------------------- Reporter: honnza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10477, #9940 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by thomie): * architecture: x86 => Unknown/Multiple * related: => #10477, #9940 Comment: Thank you for the report. If you do manage to find a way to reproduce the problem, please let us know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:41:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:41:46 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.d88184a7f40c2df1e3aea52a5acd5895@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc1 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): Phab:D1744 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Indeed this has been merged as 9578cb21275b85f5f80e01d7ea70157d8b71e9eb. Thanks for noticing this, thomie! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:46:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:46:44 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.8196646d4b4805d0abea8fd9079ab441@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: 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 bgamari): * failure: None/Unknown => GHC rejects valid program Comment: Hmm, it seems that type application didn't resolve this. What is the status of this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:48:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:48:22 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.7c2395c6c9a811f02ad347bd85190ab4@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 thomie): * status: new => patch Comment: alexvieth: your patch is missing a test. See [wiki:Building/RunningTests/Adding]. Also, make sure your patch [wiki:TestingPatches validates]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 12:56:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 12:56:20 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms In-Reply-To: <051.f6994676afcea2faaae7090f3210796a@haskell.org> References: <051.f6994676afcea2faaae7090f3210796a@haskell.org> Message-ID: <066.879484b4463138f1a27ed8f024ecd21f@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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 thomie): * keywords: => PatternSynonyms * cc: mpickering (added) * version: 8.1 => 8.0.1-rc1 * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 13:08:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 13:08:09 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.a74163f152fdde36c4451ec17ba16407@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | 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 thomie): * priority: high => highest * version: 8.1 => 7.11 Comment: I believe regressions are release blockers. Setting priority to highest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 13:13:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 13:13:51 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.fa362f60284d068c321ae418459e7c0f@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: wontfix | Keywords: Read, report- | impact 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 varosi): I have already written my own Attoparsec parser for that. For me at first sight it was a bug, because I used to use ".[decimal]" for floats on other languages. Okay, thank you for the thorough research about it! For all those reasons it seems that current implementation is the right way to be done in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 14:00:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 14:00:47 -0000 Subject: [GHC] #10476: Wrong ar during cross-compilation In-Reply-To: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> References: <046.928a748c0b21fd917210dee4be8c618c@haskell.org> Message-ID: <061.9f1dc7924b78eb336c0f614e42aa1f61@haskell.org> #10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: thomie Type: bug | Status: closed Priority: low | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: cross- | compiling Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: Phab:D1231 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 14:30:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 14:30:02 -0000 Subject: [GHC] Batch modify: #9289, #9291, #9342, #9353, #9441, #9476, #9542, ... Message-ID: <20160110143002.4E6E53A2FF@ghc.haskell.org> Batch modification to #9289, #9291, #9342, #9353, #9441, #9476, #9542, #9617, #9645, #9659 by thomie: failure to Runtime performance bug -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 14:50:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 14:50:28 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code Message-ID: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (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: -------------------------------------+------------------------------------- Here is the affected code with all package dependencies removes: {{{ $ cat PairMismatch.hs module PairMismatch (inverseFrequencyModulationChunk) where newtype VectorLazy a = VectorLazy a newtype Vector a = Vector a newtype Pointer a = Pointer a empty :: VectorLazy a empty = undefined cons :: Vector a -> Pointer a cons = undefined unfoldrResult :: (a -> Either c (b, a)) -> a -> (VectorLazy b, c) unfoldrResult = undefined switchL :: b -> (a -> Pointer a -> b) -> Pointer a -> b switchL = undefined inverseFrequencyModulationChunk :: (Num t, Ord t) => (s -> Maybe (t,s)) -> (t,s) -> Vector v -> (VectorLazy v, Maybe (t,s)) inverseFrequencyModulationChunk nextC (phase,cst0) chunk = let {- switch :: (Maybe (t, s) -> r) -> ((t, v) -> (s, Pointer v) -> r) -> t -> (s, Pointer v) -> r -} switch l r t (cp0,xp0) = maybe (l Nothing) (\(c1,cp1) -> switchL (l (Just (t,cp0))) (\x1 xp1 -> r (t+c1,x1) (cp1,xp1)) xp0) (nextC cp0) {- go :: (t,v) -> (s, Pointer v) -> Either (Maybe (t,s)) (v, ((t,v), (s, Pointer v))) -} go (c,x) cxp = if c<1 then switch Left go c cxp else Right (x, ((c-1,x),cxp)) in switch ((,) empty) (curry $ unfoldrResult (uncurry go)) phase (cst0, cons chunk) $ ghci-8.0.0.20160109 PairMismatch.hs GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling PairMismatch ( PairMismatch.hs, interpreted ) PairMismatch.hs:35:24: error: ? Couldn't match type ?a? with ?(t, s)? ?a? is a rigid type variable bound by a type expected by the context: forall a. Maybe a at PairMismatch.hs:35:24 Expected type: forall a. Maybe a Actual type: Maybe (t, s) ? In the first argument of ?l?, namely ?(Just (t, cp0))? In the first argument of ?switchL?, namely ?(l (Just (t, cp0)))? In the expression: switchL (l (Just (t, cp0))) (\ x1 xp1 -> r (t + c1, x1) (cp1, xp1)) xp0 ? Relevant bindings include cp1 :: s (bound at PairMismatch.hs:33:20) c1 :: t (bound at PairMismatch.hs:33:17) cp0 :: s (bound at PairMismatch.hs:30:22) t :: t (bound at PairMismatch.hs:30:19) r :: (t, t1) -> (s, Pointer t1) -> b (bound at PairMismatch.hs:30:17) switch :: ((forall a. Maybe a) -> b) -> ((t, t1) -> (s, Pointer t1) -> b) -> t -> (s, Pointer t1) -> b (bound at PairMismatch.hs:30:8) inverseFrequencyModulationChunk :: (s -> Maybe (t, s)) -> (t, s) -> Vector v -> (VectorLazy v, Maybe (t, s)) (bound at PairMismatch.hs:22:1) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) Failed, modules loaded: none. }}} It works with GHC-7.10.3 and before. I may try to further simplify the code and choose a better ticket header, if I got an idea what went wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 14:53:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 14:53:53 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.e0d7f416cbdc112bc32c8131fb8d76cb@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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 thomie): * cc: gkaracha (added) Comment: George, how hard would it be to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 14:56:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 14:56:38 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.ae04284d47cf7bb7a37fd77788bc8f9d@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 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 Lemming): * Attachment "PairMismatch.hs" added. Offending module as a separate file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 15:32:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 15:32:53 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.283a7b5ae88031ef5444042856a10104@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:1 thomie]: > George, how hard would it be to do this? Not very if we agree how we want the messages to look like. At the moment function `dsPmWarn` in `deSugar/Check.hs` takes the location **of the whole match**, so that it can say that "the following clauses of this match are redundant..". Every clause is an `LMatch` so we have location information available if we want to use this instead of the location of the match. My question is, do we want a separate warning for every redundant clause, or we want the 1 warning/match (what we currently have), just with more information in it? E.g. something like the following: {{{ Bug.hs:22:3: Warning: Pattern match(es) are overlapped In an equation for ?show?: Bug.hs:24:3: len _ = ... Bug.hs:25:3: len _ = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 15:57:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 15:57:44 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.030c420d5b6ef67192563d5ee72a020e@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | 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): When I said "known type" I meant the type of the variable * given by a signature (or determined by bidirectional type inference) at the binding site, if it is in the same group of mutually-recursive declarations; or * determined after type-checking, if it is in a previous group of declarations. Under this approach, the following would work: {{{#!hs f (x :: A) = x { a = 5 } g :: A -> A g x = x { a = 5 } h = aThing { a = 5 } }}} whereas these would not: {{{#!hs k x = (x :: A, x { a = 5 }) l (x :: Bool -> A) = (x True) { a = 5 } }}} This is a similar distinction to that made in bidirectional type inference for higher-rank types, where variables can be given a polymorphic type scheme by a signature or a pushed-in scheme, but inferred types must be monomorphic. I think it's easy to implement (and I've done so): given an update of a variable, look up the Id and check if its (un-zonked) type is a TyCon. One downside is that it invalidates certain syntactic transformations, such as inlining or lambda-lifting. But so do lots of other things! I've also experimented with an alternative approach: use the inferred type of the expression being updated. This is extremely easy to implement, as it simply requires deleting one guard. Moreover, it covers all the above cases and lots more. However, it doesn't have a nice declarative specification; it is rather dependent on the typechecker implementation. For example, {{{#!hs k x = (x :: A, x { a = 5 }) }}} is accepted but {{{#!hs k' x = (x { a = 5 }, x :: A) }}} is not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 15:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 15:59:08 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.b73eeef420756ab0a8e5c83f64fc6d17@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by adamgundry): I see, the above works with the `:t` command in GHCi, but trying to evaluate it or compile it in a module gives this error: {{{ ? Illegal polymorphic or qualified type: forall a1. a1 -> a1 GHC doesn't yet support impredicative polymorphism ? When checking the inferred type t :: forall b. ((forall a. a -> a) -> b) -> [forall a. a -> a] -> [b] }}} Should this message mention `ImpredicativeTypes`? In theory, it ought to be possible to actually use `ImpredicativeTypes` now if you insert enough type applications. However, the following example compiles, and I think it shouldn't: {{{#!hs {-# LANGUAGE RankNTypes, TypeApplications #-} module T11355 where t = map @(forall a . a -> a) ($ True) [id] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:01:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:01:53 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.5431bedbe0e2fadad8c7e260e6176ba5@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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: | -------------------------------------+------------------------------------- Comment (by thomie): I would maybe prefer separate warnings, such that even for a single redundant clause, the warning message doesn't have to mention two different line numbers (one for the location of the whole match, and one for the location of the redundant clause). I don't know if there is precedent for multiple line numbers in a warning message. Either way is fine though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:02:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:02:19 -0000 Subject: [GHC] #11387: Typecasting using type application syntax In-Reply-To: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> References: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> Message-ID: <066.41b46864c089efd59a27d2a875d74d95@haskell.org> #11387: Typecasting using type application syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: It would make sense to do something a bit like this. If `a :: *` is a type, then a `Typeable a` constraint is essentially an (invisible) singleton witness to `a`; the visible singleton is `TypeRep a`. I think the Right Thing to do would be to get rid of the singleton construction and add pi-types, so that we have {{{#!hs doubleWhenInt :: pi a . a -> a doubleWhenInt @Int n = n + n doubleWhenInt @_ x = x }}} The `pi a .` quantifier corresponds to `forall a . Typeable a =>`. The type argument is operationally relevant, can be pattern-matched and hence is non-parametric. The argument would be invisible-by-default (e.g. you might write `doubleWhenInt True` at a call site) but could be made visible like other type arguments (e.g. `doubleWhenInt @Int 42` should be allowed). (It's not completely obvious whether arguments to pi-quantified functions should be in the type namespace or the term namespace, because they exist at both levels.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:10:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:10:21 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.9567468e220390370c267f602ec6ce81@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms 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) Comment: Yes, this is a good idea. It would give a much nicer way to bind (particularly existential) type variables than the current `ScopedTypeVariables` hack. I think typecase should be treated separately though, and with lower priority (cf. #11387). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:10:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:10:37 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.cede326dd17382bb55e240bfdf682f55@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by slyfox): * cc: slyfox (added) Comment: changeset:5a31f231eebfb8140f9b519b166094d9d4fc2d79 and changeset:31a7bb463b6a3e99ede6de994c1f449c43a9118c dealt with similar issue on ELFv2 PPC64 but for passed arguments for a function. There is a way to detect a prototype skew by building ghc with CFLAGS/LDFLAGS=-flto. With this hack i've fixed a few SIGSEGVs on ia64 where pointers differ from function pointers (like changeset:d82f592522eb8e063276a8a8c87ab93e18353c6b) GHC still has a lot of mismatching prototypes though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:12:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:12:17 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.4014901f343580e46db93ade8a24b569@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): my mk/build.mk for the LTO test is: {{{ CPUS=9 SRC_CC_OPTS += -flto=$(CPUS) -ffat-lto-objects SRC_LD_OPTS += -flto=$(CPUS) -ffat-lto-objects SRC_HC_OPTS += -optc-flto=$(CPUS) -optc-ffat-lto-objects SRC_HC_OPTS += -optl-flto=$(CPUS) -optl-ffat-lto-objects }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:14:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:14:15 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.594243c512a0e91c465fd27a4f18bfaf@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kosmikus): I also noticed that {{{ $ ghci -XTypeInType -XTypeApplications -XScopedTypeVariables -fprint- explicit-foralls GHCi, version 7.11.20151229: http://www.haskell.org/ghc/ :? for help Prelude> data Prox a = Prox Prelude> prox1 :: forall a . Prox a; prox1 = Prox Prelude> prox2 :: forall (a :: k) . Prox a; prox2 = Prox Prelude> :t prox1 prox1 :: forall {k} (a :: k). Prox a Prelude> :t prox2 prox2 :: forall k (a :: k). Prox a }}} Is this difference in treatment deliberate? I would have expected that for `k` to be explicit, I'd have to write {{{ Prelude> prox3 :: forall k (a :: k). Prox a; prox3 = Prox }}} Is there a way to mention a type/kind variable but to still make it implicit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:24:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:24:04 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.e258a50232c8332ece6307eb30bc388c@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Is there a way to mention a type/kind variable but to still make it implicit? I doubt it. You don't even have to write `forall a .` to make `a` explicit in `prox1`. {{{ rwbarton at morphism:~/zulip$ ~/ghc-newest/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160107: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType -XTypeApplications -XScopedTypeVariables -fprint-explicit-foralls Prelude> data Prox a = Prox Prelude> prox0 :: Prox a; prox1 = Prox Prelude> :t prox0 prox0 :: forall {k} (a :: k). Prox a }}} Based on experimentation, the rule seems to be: all type variables mentioned in the type signature are explicit, from left to right as they appear in the signature. I guess `k` counts as to the left of `a` in `a :: k`, though, since it is implicitly quantified earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:46:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:46:05 -0000 Subject: [GHC] #11398: Type application for operator sections Message-ID: <051.8090d23f1a35833fa5abdb4fb4d371ce@haskell.org> #11398: Type application for operator sections -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `-fprint-explicit-foralls` {{{#!hs (+ 1) :: forall {a}. Num a => a -> a }}} This means we cannot apply it to a type: {{{#!hs (+ 1) @Int :: Int -> Int }}} Since sections are sugar `(+ 1)` could be given the type `forall a. Num a => a -> a` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 16:50:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 16:50:47 -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.ae8c78eaf7c805665d40b2995f87857c@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): seeing same issue and performance on 7.10.3. This is on MacOS but I believe the problem occurs on multiple platforms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 17:47:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 17:47:22 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.6a88090bafc49122f7ac2f9b78f3d5f4@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): To get generated code we can run: {{{ "inplace/bin/ghc-stage1" \ -static -H64m -O1 \ -optc-flto=9 -optc-ffat-lto-objects \ -optl-flto=9 -optl-ffat-lto-objects \ -optc-ggdb2 -optl-ggdb2 \ -j4 \ -optc-Werror=implicit-function-declaration -optc-Werror=overflow \ -Wall \ -lbfd \ -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \ -DCOMPILING_RTS -this-package-key rts \ -optc-DNOSMP -dcmm-lint \ -i -irts -irts/dist/build \ -irts/dist/build/autogen \ -Irts/dist/build -Irts/dist/build/autogen \ -O2 \ -C rts/Exception.cmm \ -o rts/dist/build/Exception.hc }}} '''rts/dist/build/Exception.hc''' contains the following declarations: {{{ /* (incomplete) symbol declaraion */ EF_(raiseExceptionHelper); ... /* exact prototype dectaration, assignment and call: */ { W_ (*ghcFunPtr)(void *, void *, void *); ghcFunPtr = ((W_ (*)(void *, void *, void *))raiseExceptionHelper); _c2y = ghcFunPtr((void *)(W_)BaseReg, (void *)(W_)CurrentTSO, (void *)_c2z);;} }}} It comes from '''rts/Exception.cmm''': {{{ retry_pop_stack: SAVE_THREAD_STATE(); (frame_type) = ccall raiseExceptionHelper(BaseReg "ptr", CurrentTSO "ptr", exception "ptr"); LOAD_THREAD_STATE(); }}} As we see unannotated return type defaults to '''W_''' ('''StgWord''', non-pointer type). So the question is: Does gcc ignore type coercion given in '''ghcFunPtr =''' assignment and uses original declaration? gcc's '''-fdump-*-all''' options might hint at where gcc loses information about argument type. Could it be real (but similar) error happens somewhere else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 17:52:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 17:52:29 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic Message-ID: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE FlexibleInstances, TypeInType #-} module FvProvFallsIntoAHole where import Data.Kind newtype UhOh (k :: * -> *) (a :: k *) = UhOh (k *) instance Functor k => Functor (UhOh k) where }}} produces this GHC panic: {{{ $ /opt/ghc/head/bin/ghc FvProvFallsIntoAHole.hs [1 of 1] Compiling FvProvFallsIntoAHole ( FvProvFallsIntoAHole.hs, FvProvFallsIntoAHole.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160108 for x86_64-unknown-linux): fvProv falls into a hole {aq6} 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 Sun Jan 10 18:06:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 18:06:19 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.83de446650bb503c635b7001e4d3c65b@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): One more note: The bug you describe should surface on amd64 if you change return type from 'int' (%rax) to 'double' (%xmm0) in your example, correct? On gcc-5.3.0/amd64 it seems to work as expected: {{{ call double_returning_function cvttsd2si %xmm0, %eax cmpl $42, %eax }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 18:58:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 18:58:21 -0000 Subject: [GHC] #11400: * is not an indexed type family Message-ID: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can't seem to create an indexed data family using the kind `*` with `-XTypeInType` enabled. I have to work around it by using `Type`: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160108: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeInType -XTypeFamilies ?> import Data.Kind ?> data family IdxProxy k (a :: k) ?> data instance IdxProxy * a :5:1: error: ? Illegal family instance for ?*? (* is not an indexed type family) ? In the data instance declaration for ?*? ?> data instance IdxProxy Type a ?> :kind! IdxProxy * IdxProxy * :: * -> * = IdxProxy * ?> :kind! IdxProxy Type IdxProxy Type :: Type -> * = IdxProxy Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 19:05:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 19:05:27 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.c16d4b842b6c2b2831d1a09d549f047d@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): Actually, this might just be a parser issue, not a data family issue. I can also get the above instance to work by typing it in as {{{#!hs data instance IdxProxy (*) a }}} Which leads me to believe that GHC is parsing {{{data instance IdxProxy * a}}} as {{{data instance (*) IdProxy a}}}?that is, it's interpreting `*` as an infix type operator (as evidence, typing in the latter declaration gets the same error message the former). I'm not sure how tricky it would be to detangle the parser in this case, since I'm not sure how GHC knows to choose `Data.Kind.*` over an infix type operator that happens to be named `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 19:21:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 19:21:59 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.71c1a304a087359937f7088dd8ec4a46@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.1 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'm currently implementing CSE in STG level. I'm almost done implementing the infrastructure ({{{TrieMap}}} etc.). I'll update the thread once I get some results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 19:56:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 19:56:16 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest Message-ID: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- With the llvm-tf package I got the following problem: {{{ $ cat RecordSelectorCtevDest.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module RecordSelectorCtevDest where import Data.Word (Word32, ) import Foreign.Ptr (Ptr, ) newtype Value a = Value a newtype Function a = Function a newtype CodeGenFunction r a = CodeGenFunction a bind :: CodeGenFunction r a -> (a -> CodeGenFunction r b) -> CodeGenFunction r b bind (CodeGenFunction a) k = k a class (f ~ CalledFunction g, r ~ CallerResult g, g ~ CallerFunction f r) => CallArgs f g r where type CalledFunction g :: * type CallerResult g :: * type CallerFunction f r :: * call :: Function f -> g instance CallArgs (IO a) (CodeGenFunction r (Value a)) r where type CalledFunction (CodeGenFunction r (Value a)) = IO a type CallerResult (CodeGenFunction r (Value a)) = r type CallerFunction (IO a) r = CodeGenFunction r (Value a) call = undefined instance CallArgs b b' r => CallArgs (a -> b) (Value a -> b') r where type CalledFunction (Value a -> b') = a -> CalledFunction b' type CallerResult (Value a -> b') = CallerResult b' type CallerFunction (a -> b) r = Value a -> CallerFunction b r call = undefined test :: Function (IO (Ptr a)) -> Function (Ptr a -> IO Word32) -> CodeGenFunction Word32 (Value Word32) test start fill = bind (call start) (call fill) $ ghci-8.0.0.20160109 RecordSelectorCtevDest.hs GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling RecordSelectorCtevDest ( RecordSelectorCtevDest.hs, interpreted ) *** Exception: No match in record selector ctev_dest }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 19:56:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 19:56:41 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.cdbb87d57342e88e7a2d0f115f5033bc@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 Lemming): * Attachment "RecordSelectorCtevDest.hs" added. Example module as file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 20:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 20:14:10 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.cc3094f6a19286b87cd9efbda0248ecd@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 Lemming: Old description: > With the llvm-tf package I got the following problem: > {{{ > $ cat RecordSelectorCtevDest.hs > > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FlexibleInstances #-} > module RecordSelectorCtevDest where > > import Data.Word (Word32, ) > import Foreign.Ptr (Ptr, ) > > newtype Value a = Value a > newtype Function a = Function a > newtype CodeGenFunction r a = CodeGenFunction a > > bind :: CodeGenFunction r a -> (a -> CodeGenFunction r b) -> > CodeGenFunction r b > bind (CodeGenFunction a) k = k a > > class > (f ~ CalledFunction g, r ~ CallerResult g, g ~ CallerFunction f r) => > CallArgs f g r where > type CalledFunction g :: * > type CallerResult g :: * > type CallerFunction f r :: * > call :: Function f -> g > > instance CallArgs (IO a) (CodeGenFunction r (Value a)) r where > type CalledFunction (CodeGenFunction r (Value a)) = IO a > type CallerResult (CodeGenFunction r (Value a)) = r > type CallerFunction (IO a) r = CodeGenFunction r (Value a) > call = undefined > > instance CallArgs b b' r => CallArgs (a -> b) (Value a -> b') r where > type CalledFunction (Value a -> b') = a -> CalledFunction b' > type CallerResult (Value a -> b') = CallerResult b' > type CallerFunction (a -> b) r = Value a -> CallerFunction b r > call = undefined > > test :: > Function (IO (Ptr a)) -> > Function (Ptr a -> IO Word32) -> > CodeGenFunction Word32 (Value Word32) > test start fill = bind (call start) (call fill) > > $ ghci-8.0.0.20160109 RecordSelectorCtevDest.hs > GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling RecordSelectorCtevDest ( RecordSelectorCtevDest.hs, > interpreted ) > *** Exception: No match in record selector ctev_dest > }}} New description: With the llvm-tf package I got the following problem: {{{ $ cat RecordSelectorCtevDest.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module RecordSelectorCtevDest where newtype Value a = Value a newtype CodeGen r a = CodeGen a bind :: CodeGen r a -> (a -> CodeGen r b) -> CodeGen r b bind (CodeGen a) k = k a class (f ~ CalledFunction g, r ~ CallerResult g, g ~ CallerFunction f r) => CallArgs f g r where type CalledFunction g :: * type CallerResult g :: * type CallerFunction f r :: * call :: f -> g instance CallArgs (IO a) (CodeGen r (Value a)) r where type CalledFunction (CodeGen r (Value a)) = IO a type CallerResult (CodeGen r (Value a)) = r type CallerFunction (IO a) r = CodeGen r (Value a) call = undefined instance CallArgs b b' r => CallArgs (a -> b) (Value a -> b') r where type CalledFunction (Value a -> b') = a -> CalledFunction b' type CallerResult (Value a -> b') = CallerResult b' type CallerFunction (a -> b) r = Value a -> CallerFunction b r call = undefined test :: IO a -> (a -> IO ()) -> CodeGen () (Value ()) test start stop = bind (call start) (call stop) $ ghci-8.0.0.20160109 RecordSelectorCtevDest.hs GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling RecordSelectorCtevDest ( RecordSelectorCtevDest.hs, interpreted ) *** Exception: No match in record selector ctev_dest }}} The problem disappears when I remove the 'r' parameter from CodeGen, CallArgs and CallerFunction and remove the CallerResult consequently. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 21:33:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 21:33:52 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.ec1741b280279d12918605a62f388fa8@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): Filed a bug upstream to investigate further and/or find a workaround: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 21:43:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 21:43:20 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.ae7bd740c5afc360883a838f03ef2308@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by mkarcher): I can confirm your obvservation that on amd64, gcc 5.3.1 does indeed take the type of the function pointer into account when it decides whether the return value is in %eax (for int), %rax (for void*) or %xmm0 (for double). It's interesting that gcc doesn't do it on m68k. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 22:03:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 22:03:17 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.b4abbcd499fb2ad10ab0213220bbae58@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by mkarcher): It seems gcc introduces a temporary double variable in the double/int mismatch on amd64, because the double-to-int conversion is a semantic conversion changing the representation. On the other hand, the void*-to- int conversion is reinterpreting the same value as a different type without the need of a conversion instruction (like cvttsd2si in the amd64 case). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 22:59:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 22:59:47 -0000 Subject: [GHC] #11398: Type application for operator sections In-Reply-To: <051.8090d23f1a35833fa5abdb4fb4d371ce@haskell.org> References: <051.8090d23f1a35833fa5abdb4fb4d371ce@haskell.org> Message-ID: <066.0b74f61e2f548edfa2a01993ea8e627e@haskell.org> #11398: Type application for operator sections -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): What's the typing rule you're proposing? It's awfully easy to find cases like this one where the behavior is straightforward, but coming up with a consistent rule is quite hard. Take `const`. What type should {{{(`const` undefined)}}} have? `forall a. a -> a`? `forall a b. a -> a`? What about {{{(undefined `const`)}}}? In the end, I think this is a no-go, for exactly the same reason that applied functions have inferred type parameters, not specified ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 23:05:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 23:05:19 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.fd9932016d7d39ab2d1df556fece7b41@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Originally reported [https://mail.haskell.org/pipermail/ghc- > devs/2016-January/010915.html here]. When applying types via > `-XTypeApplications`, the type/kind that gets instantiated seems to be > different depending on whether you're using functions, datatypes, or > typeclasses. > > Here's an example contrasting functions and datatypes: > > {{{ > $ /opt/ghc/head/bin/ghci > GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help > ?> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType > ?> data Prox a = Prox > ?> prox :: Prox a; prox = Prox > ?> :t prox > prox :: forall k (a :: k). Prox k a > ?> :t prox @Int > prox @Int :: Prox * Int > ?> :t Prox > Prox :: forall k (a :: k). Prox k a > ?> :t Prox @Int > Prox @Int :: Prox Int a > }}} > > This is the core of the problem: with a function, `Int` seems to be > applied to type variable `a`, whereas with data types, `Int` appears to > be applied to the kind variable `k`. This confuses me, since `k` wasn't > specified anywhere in the definition of `Prox`. > > Andres L?h also [https://mail.haskell.org/pipermail/ghc- > devs/2016-January/010916.html observed] a similar discrepancy between > functions and typeclasses: > > {{{ > ?> :set -XScopedTypeVariables > ?> class C a where c :: () > ?> d :: forall a. C a => (); d = c @_ @a > ?> :t d > d :: forall k (a :: k). C k a => () > ?> :t d @Int > d @Int :: C * Int => () > ?> :t c > c :: forall k (a :: k). C k a => () > ?> :t c @Int > c @Int :: C Int a => () > ?> :t c @_ @Int > c @_ @Int :: C * Int => () > }}} New description: Originally reported [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010915.html here]. When applying types via `-XTypeApplications`, the type/kind that gets instantiated seems to be different depending on whether you're using functions, datatypes, or typeclasses. Here's an example contrasting functions and datatypes: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType ?> data Prox a = Prox ?> prox :: Prox a; prox = Prox ?> :t prox prox :: forall k (a :: k). Prox k a ?> :t prox @Int prox @Int :: Prox * Int ?> :t Prox Prox :: forall k (a :: k). Prox k a ?> :t Prox @Int Prox @Int :: Prox Int a }}} This is the core of the problem: with a function, `Int` seems to be applied to type variable `a`, whereas with data types, `Int` appears to be applied to the kind variable `k`. This confuses me, since `k` wasn't specified anywhere in the definition of `Prox`. Andres L?h also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010916.html observed] a similar discrepancy between functions and typeclasses: {{{ ?> :set -XScopedTypeVariables ?> class C a where c :: () ?> d :: forall a. C a => (); d = c @_ @a ?> :t d d :: forall k (a :: k). C k a => () ?> :t d @Int d @Int :: C * Int => () ?> :t c c :: forall k (a :: k). C k a => () ?> :t c @Int c @Int :: C Int a => () ?> :t c @_ @Int c @_ @Int :: C * Int => () }}} EDIT: See also documentation infelicity in comment:9. -- Comment (by goldfire): Replying to [comment:8 rwbarton]: > Based on experimentation, the rule seems to be: all type variables mentioned in the type signature are explicit, from left to right as they appear in the signature. I guess `k` counts as to the left of `a` in `a :: k`, though, since it is implicitly quantified earlier. Here are the rules: * All variables mentioned by name are specified. * To get the ordering, list all the variables ordered left-to-right by first occurrence. Then do a stable topological sort based on dependencies. The second bullet is why `k` goes before `a` even though `a` is mentioned first. There is a note about this in the manual, but it doesn't discuss the topological sort part. Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 10 23:10:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jan 2016 23:10:41 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.41beceb5f6501d75543dc90c95a07b32@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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 don't see a problem thus far. But as I said in my previous comment, you may need to unify that result kind with `*` in the datatype case somewhere. Perhaps a `_ <- unifyType blah blah (typeKind res_ty) liftedTypeKind` would do the trick, but perhaps something more elaborate is necessary. I do think you're pushing in the right direction, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 01:40:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 01:40:35 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.f887a92ba08c48f8c3b188c8d9b93a2f@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | 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): Something fishy is going on with the kind of the `ProxyFam` instance `TyCon`. I added `pprTrace`-ed the result of `tyConKind tc` right before the call to `filterOutInvisibleTypes` mentioned above, and noticed a discrepancy between datatypes and data families: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160109: http://www.haskell.org/ghc/ :? for help ?> :set -XDeriveGeneric -XTypeFamilies -XPolyKinds -fprint-explicit- foralls ?> import GHC.Generics ?> data Proxy (a :: k) = Proxy deriving Generic1 tc: Proxy tyConKind tc: forall k_a1Gj. k_a1Gj -> * tc_args: [*] filterOutInvisibleTypes tc tc_args: [] all isTyVarTy: True ?> data family ProxyFam (a :: k) ?> data instance ProxyFam (a :: k) = ProxyCon deriving Generic1 tc: R:ProxyFamka tyConKind tc: forall k_a1Ps -> k_a1Ps -> * tc_args: [*] filterOutInvisibleTypes tc tc_args: [*] all isTyVarTy: False :5:53: error: ? Can't make a derived instance of ?Generic1 ProxyFam?: ProxyFam must not be instantiated; try deriving `ProxyFam k a' instead ? In the data instance declaration for ?ProxyFam? }}} Notice that `tyConKind` for the datatype `Proxy` is `forall k. k -> *` (i.e., `k` is specified but not visible), but the `tyConKind` for the `ProxyFam` instance is `forall k -> k -> *` (`k` is visible)! This is definitely the reason why this bug is manifesting itself, although I'm not sure why `k` is a visible type argument in the `ProxyFam` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 04:55:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 04:55:18 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.e9258e27b525f8ddc7f9ddce59cce4d7@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 05:30:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 05:30:46 -0000 Subject: [GHC] #11402: Add Peano numbers Message-ID: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> #11402: Add Peano numbers -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 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: -------------------------------------+------------------------------------- I have seen these redefined many times now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 05:40:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 05:40:33 -0000 Subject: [GHC] #11402: Add Peano numbers In-Reply-To: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> References: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> Message-ID: <063.e64b83c28e2cb422b12e8e329e4f2930@haskell.org> #11402: Add Peano numbers -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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): Phab:D1760 Wiki Page: | -------------------------------------+------------------------------------- Changes (by strake888): * status: new => patch * differential: => Phab:D1760 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 09:18:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 09:18:25 -0000 Subject: [GHC] #11402: Add Peano numbers In-Reply-To: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> References: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> Message-ID: <063.6894cfd73e45999c4480c2c7b5498f9b@haskell.org> #11402: Add Peano numbers -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | 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): Phab:D1760 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => infoneeded Comment: As this affects `base`, this will need to go through the formal core libraries proposal process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 09:21:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 09:21:08 -0000 Subject: [GHC] #11386: Improve error message In-Reply-To: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> References: <051.64b4ac544b1736e7961207b55efbfb34@haskell.org> Message-ID: <066.b09d876c89dcfcdad7a10583b8fb916f@haskell.org> #11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10362 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you had written {{{ class T A b }}} Then the error would have been fine. What is special here? Just that it's using a type constructor that has built-in syntax. I expect I could add a special case to dis-allow such class declarations, and I agree this one is strange because of the `%` signs. But is it really worth the trouble? Will people do this much? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 10:55:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 10:55:58 -0000 Subject: [GHC] #11403: Provide a way to make fast in-calls into Haskell Message-ID: <047.229ab9cf5012cda52cb555166898d5f0@haskell.org> #11403: Provide a way to make fast in-calls into Haskell -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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, there is no way to call into Haskell without creating a new Haskell thread and running the schedular, which is rather slow. It would be nice to be able to make faster calls into Haskell, even if some state had to be persisted on the C side and passed to the RTS each time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 10:56:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 10:56:21 -0000 Subject: [GHC] #11403: Provide a way to make fast in-calls into Haskell In-Reply-To: <047.229ab9cf5012cda52cb555166898d5f0@haskell.org> References: <047.229ab9cf5012cda52cb555166898d5f0@haskell.org> Message-ID: <062.4f160a28c9eb96325d85edb812da983a@haskell.org> #11403: Provide a way to make fast in-calls into Haskell -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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 dobenour): * cc: simonmar (added) * component: Compiler => Runtime System * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 10:57:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 10:57:43 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.52d296e357f874047910d1cd0d320107@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CustomTypeErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 10:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 10:58:39 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.f3c82e21b085d49456ef1ba2b7f3c65e@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: diatchki Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => diatchki Comment: Iavor this is you, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:04:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:04:09 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup In-Reply-To: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> References: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> Message-ID: <057.733ec5160a22313ddf7a0737baaa18ee@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: pattern | checker, 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: pattern checker => pattern checker, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:05:04 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.d84c9eb32ea3175380b20d20d7892275@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Would it be okay to use [http://re2c.org re2c] to generate the RTS options parser? I have a patch that provides a proper options parser using it. Existing libraries like getopt did not seem suitable, due to the non- standard format of the RTS flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:05:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:05:49 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.723219806bbc02c18afd9d06d8e94f03@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings * milestone: 8.0.1 => 8.2.1 Comment: I'm re-opening with a milestone of 8.2, because I really think we can do better, and I don't want to lose track of the example. But it's not pressing for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:06:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:06:20 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.49202898d2fbdd75715950425b98b6f9@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11276, #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings * status: closed => new * resolution: fixed => * milestone: 8.0.1 => 8.2.1 Comment: Re-opening because I think we can do better for 8.2. But ok for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:06:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:06:35 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.bf48150ff644d2e6c8abd5902c26ddca@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: gkaracha => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:07:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:07:23 -0000 Subject: [GHC] #11302: GHC HEAD uses up all memory while compiling `genprimcode` In-Reply-To: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> References: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> Message-ID: <057.68fa8ca3c7d8e9cc48714481526b0099@haskell.org> #11302: GHC HEAD uses up all memory while compiling `genprimcode` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11303 #11239 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:08:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:08:07 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.0ea779a13e5f8137e945cf5082d0c475@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11163, #11276 | Differential Rev(s): Phab:D1737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings * status: closed => new * resolution: fixed => * milestone: 8.0.1 => 8.2.1 Comment: Re-opening to improve for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:08:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:08:30 -0000 Subject: [GHC] #11161: New exhaustiveness checker breaks concurrent/prog001 In-Reply-To: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> References: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> Message-ID: <061.6e9ffe7edd4b5e294450ba8529fa05ec@haskell.org> #11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: gkaracha => * keywords: => PatternMatchWarnings * status: closed => new * resolution: fixed => Comment: Re-opening to improve for 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:08:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:08:46 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker In-Reply-To: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> References: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> Message-ID: <061.c5baa4a688ba9b50907699dec650a592@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T783 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 Mon Jan 11 11:09:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:09:07 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 In-Reply-To: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> References: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> Message-ID: <061.718d1c81e81d882a63c6cb9b3976360f@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: pattern checker => pattern checker, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:09:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:09:27 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.3e703b62a9831aca6cc48b4a333e04aa@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings * status: closed => new * resolution: fixed => * owner: goldfire => * milestone: 8.0.1 => 8.2.1 Comment: Re-opening for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:09:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:09:47 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.6108b0ef55913554c7beb9c74d32c716@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: pattern | checker, 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: pattern checker => pattern checker, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:11:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:11:26 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.000a7e4414d7df23bd6856208c43fb97@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings, | 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: warnings => warnings, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:12:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:12:29 -0000 Subject: [GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis In-Reply-To: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> References: <046.7124d47aa8c745a5f8757fe53c21a64c@haskell.org> Message-ID: <061.992d521c85c5ac129f020ca92fdbe90b@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7669 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:18:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:18:06 -0000 Subject: [GHC] #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) In-Reply-To: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> References: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> Message-ID: <062.24fca0d31713f921d605cb89e4b3ec48@haskell.org> #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | matching, exhaustiveness, pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #595 | Differential Rev(s): Wiki Page: | PatternMatchCheck, | PatternMatchCheckImplementation | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: pattern matching, exhaustiveness, pattern checker => pattern matching, exhaustiveness, pattern checker, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:21:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:21:23 -0000 Subject: [GHC] #11393: Ability to define INLINE pragma for all instances of a given typeclass In-Reply-To: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> References: <046.bece46cf8d91598cae1617ab9dbc20e9@haskell.org> Message-ID: <061.afd0d9a885e6615f868472bd78d9e7e2@haskell.org> #11393: Ability to define INLINE pragma for all instances of a given typeclass -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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'm not sure this is a good plan. * What if someone writes a bug instance declaration? Having an `{-# INLINE #=}` pragma written somewhere else entirely might be highly unexpected. * The `{-# INLINE #-}` pragma in a class decl applies to the default method declaration in that class decl. We'd need a way to get the current behaviour (i.e. inline the default method, but no effect on instances that define their own method for `foo`). Seems doubtful to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:22:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:22:44 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.97d9ceabd662815c37de0cc7cb5c6a5c@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.8.2 checker) | 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): The trouble here is that we don't have even a partial solution in mind. Ideas welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 11:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 11:31:13 -0000 Subject: [GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` In-Reply-To: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> References: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> Message-ID: <062.41c2e8bd239d0bb5d0d427722d4849eb@haskell.org> #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: kseo Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 kseo): * owner: => kseo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 12:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 12:17:17 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.da4c4e713a3b88d3cfca53257c5a4481@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 jstolarek): I've run into the same problem. I think this is a ''wontfix''. Richard promised to document the need for parens in the User's Guide, but I don't think he did that yet. Is this the relevant section: http://downloads.haskell.org/~ghc/master/users-guide//glasgow_exts.html #promoting-type-operators ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 12:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 12:29:47 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.0ed69900b1a16b953cf94291c306ebae@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | 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 Mon Jan 11 12:42:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 12:42:16 -0000 Subject: [GHC] #11404: The type variable used in a kind is still used Message-ID: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> #11404: The type variable used in a kind is still used -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Phab:D1739. When you say {{{ undefined :: forall (v :: Levity) (a :: TYPE v). (?callStack :: CallStack) => a }}} you get a warning that `v` is unused. I will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 12:43:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 12:43:53 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check Message-ID: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Phab:D1739. When you say {{{ undefined :: forall (v :: Levity). forall (a :: TYPE v). (?callStack :: CallStack) => a }}} you get a skolem escape failure because GHC things that the kind of `(?callStack :: CallStack) => a` is `TYPE v`. It should be `*`. I will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 12:51:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 12:51:17 -0000 Subject: [GHC] #11360: Test "termination" doesn't pass with reversed uniques In-Reply-To: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> References: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> Message-ID: <061.a5b4e15a272182cfd2d418b84ba7a7d5@haskell.org> #11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: goldfire => niteria * related: => #11360 Comment: I think this is a symptom of #11360 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 13:06:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 13:06:44 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.c16fe220e281ce91bbceba58a99f71bf@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Might I suggest that we experiment with this outside of `base` for a bit? `TypeApplications` is awfully new. I honestly don't think it will, but it might well change. Given the very loud grumbling we've all heard about changes to `base`, I think it would be prudent to make a `proxyfree-base` that users can opt into. If all goes well, I think merging into `base` somehow is great. But maybe for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 13:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 13:10:09 -0000 Subject: [GHC] #11363: Parser groups "::" and "*" together in kind signature (a::*) In-Reply-To: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> References: <051.f5c7e27b6f7199ac1e7dfbc844f40f16@haskell.org> Message-ID: <066.68a23d94c4be07d16ac592ad4f3e38cc@haskell.org> #11363: Parser groups "::" and "*" together in kind signature (a::*) --------------------------------------+------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 8.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+------------------------------ Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Closing in concurrence with rwbarton. Reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 13:25:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 13:25:16 -0000 Subject: [GHC] #11364: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> References: <042.b1fe37712050c9ec3867612129666b3e@haskell.org> Message-ID: <057.4008ad09ddbdf14c90768e95eb8bb0bf@haskell.org> #11364: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): So should this ticket be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 13:28:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 13:28:45 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.50d41a03da7d19e5986ab896c5a3f177@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 14:17:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 14:17:02 -0000 Subject: [GHC] #10719: Malformed data type quotation accepted In-Reply-To: <048.6b945575ed583054da28b46717dca1a6@haskell.org> References: <048.6b945575ed583054da28b46717dca1a6@haskell.org> Message-ID: <063.bbc4c82e16b927d624f845592c4b0a37@haskell.org> #10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11341, #10828 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Closing in concurrence with jstolarek. Reopen if you feel otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 14:19:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 14:19:59 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.35b90f8bba148f3ae83d7f5a984ceca5@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): Indeed, having a complete rundown of where you need to parenthesize `*` would be extremely helpful. (I think you also need to parenthesize it when reexporting it, i.e., `type (*)`, correct?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 14:22:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 14:22:04 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.556f024f8cd298a1effec18818c79563@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): Also doesn't `TypeInType` use "`Type`" in place of "`*`"? I'm a bit confused. Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 14:25:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 14:25:12 -0000 Subject: [GHC] #11360: Test "termination" doesn't pass with reversed uniques In-Reply-To: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> References: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> Message-ID: <061.40e03c7f9527baac2bbeaa1ef1d2a60c@haskell.org> #11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think this is a symptom of #11360 But this ''is'' #11360. Did you mis-type the comment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 14:35:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 14:35:14 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.0d78f9b668cc9d9f940f8cda18439282@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 jstolarek): I believe `Type` and `*` are synonyms. So theoretically they can be used interchangeably but practically there is this special case for parsing when `*` needs to be parenthesized. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 15:06:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 15:06:26 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.3776784609b9b7596c5e625f547420ab@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 bgamari): * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 Comment: I believe this affects the current 8.0 branch as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 15:21:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 15:21:30 -0000 Subject: [GHC] #11406: RTS gets stuck in scheduleDetectDeadlock() Message-ID: <043.4d672ad8e0e056f1f6d3ce9793dde7c7@haskell.org> #11406: RTS gets stuck in scheduleDetectDeadlock() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | 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: -------------------------------------+------------------------------------- Steps to reproduce: - Compile HEAD. - Add this line to MkId.mkDataConRep: {{{#!haskell pprTrace "mkDataConRep" (text "wrap_body:" <+> ppr wrap_body) (return ()) }}} - Recompile only stage1. (stage2 will fail, see next step) - Compile any file using newly generated stage1. GHC gets stuck, not using any CPU or RAM. The stack trace: {{{ #0 0x00007fd56d570650 in __pause_nocancel () at ../sysdeps/unix/syscall- template.S:81 #1 0x0000000002174e11 in awaitUserSignals () at rts/posix/Signals.c:343 #2 0x0000000002168a6a in scheduleDetectDeadlock (pcap=, task=) at rts/Schedule.c:931 #3 schedule (task=0x42fa8e0, initialCapability=) at rts/Schedule.c:282 #4 scheduleWaitThread (tso=, ret=ret at entry=0x0, pcap=pcap at entry=0x7fffb90b7778) at rts/Schedule.c:2380 #5 0x0000000002187724 in rts_evalLazyIO (cap=cap at entry=0x7fffb90b7778, p=, ret=ret at entry=0x0) at rts/RtsAPI.c:500 #6 0x0000000002166637 in real_main () at rts/RtsMain.c:63 #7 hs_main (argc=, argv=, main_closure=, rts_config=...) at rts/RtsMain.c:114 #8 0x0000000000421fe4 in main () }}} It's basically stuck in pause() syscall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 15:39:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 15:39:21 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.cdc60d605e2b9edfa76b3edb6e68780c@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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): It'd be easier to help if you had a branch of the GHC repo, or a remote clone thereof, that Richard or I could use to reproduce what you have. I would really like a wiki page to describe the design, please. Maybe it's a simple page -- if so, so much the better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 15:49:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 15:49:13 -0000 Subject: [GHC] #11406: RTS gets stuck in scheduleDetectDeadlock() In-Reply-To: <043.4d672ad8e0e056f1f6d3ce9793dde7c7@haskell.org> References: <043.4d672ad8e0e056f1f6d3ce9793dde7c7@haskell.org> Message-ID: <058.0aa14800c0c2afc3361c4b77254ffb94@haskell.org> #11406: RTS gets stuck in scheduleDetectDeadlock() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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): This is probably an infinite loop, i.e. a blackhole. The trace you added forces something too early and causes a deadlock. For some reason we don't detect and report blackhole loops as `<>` in GHC, that is probably worth investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 15:51:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 15:51:20 -0000 Subject: [GHC] #4243: Make a proper options parser for the RTS In-Reply-To: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> References: <044.6ea5654174cc0120653bc110fe1a703c@haskell.org> Message-ID: <059.631f1b78b294e8010b1234bba3d00f4d@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'd prefer not to add a dependency on an external tool if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 16:02:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 16:02:47 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.9d1bd21beb27c85417262577412fd02a@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > OK. So the in the dynamic case GHCi SHOULD NOT (MUST NOT?) require the presence of the development versions of C libraries when using an installed Haskell package. This is currently not the case. I think we could make it so that GHCi, if using dynamic libraries, doesn't require the `-dev` version of C library dependencies, but what's the gain from doing that? GHC would still require it when not using `-dynamic`, so you wouldn't be able to omit the dependency on `-dev` in the distro packages, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 16:46:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 16:46:31 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance Message-ID: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- Compiling this code with GHC 8.1 causes all my memory to be used very quickly: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module TypeInTypeEatsAllMemory where import Data.Kind type Const a b = a data family UhOh (f :: k1) (a :: k2) (b :: k3) data instance UhOh (f :: * -> * -> *) (a :: forall a) (b :: Const * a) = UhOh }}} On the other hand, this code compiles without issue: {{{#!hs {-# LANGUAGE TypeInType #-} module TypeInTypeEatsAllMemory where import Data.Kind type Const a b = a data UhOh (f :: * -> * -> *) (a :: forall a) (b :: Const * a) = UhOh }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:02:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:02:52 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.a30ff108477fba072f5d04674955a8d5@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 gridaphobe): * priority: normal => highest Comment: Yes, this is a transitive blocker for the 8.0 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:07:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:07:01 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.44cba93a28c3f67b8a21e22e8b4dbfa7@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings, | 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 gkaracha): Actually nothing is redundant in the above examples. As we discuss in the paper (section about laziness), `(sillyId undefined)` will give you the right hand-side so the clause: {{{#!hs sillyId x = x }}} is not redundant at all. Of course, this is not the case for: {{{#!hs sillyId2 :: F1 Char -> F1 Char sillyId2 (!x) = x }}} because it is strict in the argument, so no WHNF can have the type `F1 Char`. But even in this case, the clause is not actually redundant, it just has an inaccessible RHS (remember this is not Agda). Pattern matching is not just used for discrimination in Haskell but also for evaluation, which I see as a side effect. Hence, the clause may have an inaccessible RHS, but by removing it the expression is not evaluated and you change the semantics of `sillyId2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:30:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:30:31 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.1781d9bf8649d6e81d2998f53cacadaa@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings, | 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 rwbarton): Good point. If the return type was a type with values, the clause would ''really'' not be redundant! {{{ sillyFun :: F1 Char -> String sillyFun x = "hi" }}} Surely it doesn't make sense for redundancy of a pattern match to depend on what sort of thing is on the right hand side? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:31:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:31:58 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.e735bf3d3a5bbb4436e3d0bd728200f6@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings, | 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 goldfire): I agree with George (gkaracha). `sillyId x = x` can't be called on a value, but Haskell isn't call-by-value. I will use `Void` instead of `F1 Char`, because the type family bit isn't the interesting part here. {{{ silly1 :: Void -> Void silly1 x = x silly2 :: Void -> Void silly2 x = error "urk" }}} `silly1 undefined` and `silly2 undefined` have different runtime behavior; the pattern is not redundant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:37:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:37:13 -0000 Subject: [GHC] #11356: GHC panic In-Reply-To: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> References: <051.835ef17fedac6cadd7b180cc58f9772a@haskell.org> Message-ID: <066.6c7bd796523566441bc906e95e5ac799@haskell.org> #11356: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11356 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Great -- thanks. I had been wanting to do a similar refactoring now that we have `TcTyCon`. I actually think there's even more we can do here, reducing the knot to including only the final zonk. Zonking a tycon would just look up the loopy tycon. But no more knot-tied tycons during typechecking and no more `mkNakedXXX` functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:38:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:38:58 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.f82be5237a6fe8ba827dbcf191fc3866@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings, | 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 rwbarton): In that case, GHC's behavior is correct and we can close this ticket, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:41:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:41:30 -0000 Subject: [GHC] #11408: Delicate solve order Message-ID: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> #11408: Delicate solve order -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Should we successfully infer a type for `f`: {{{ f x = [h x, [x]] }}} assuming `h :: forall b. F b -> b`? Assuming `(x::alpha)` and we instantiate `h` at `beta`, we get the constraints {{{ (1) beta ~ [alpha] from the list [h x, [x]] (2) alpha ~ F beta from the call of h }}} Now if we happen to unify the constraint (1) first, `beta := [alpha`], then we successfully infer {{{ f :: forall a. (a ~ F [a]) => a -> [[a]] }}} But if we unify the constraint (2) first, `alpha := F beta`, we get {{{ f :: forall b. (b ~ [F b]) => F b -> [[F b]] }}} which is ambiguous. Eeek! This actually shows up in type inference for `indexed- types/should_compile/IndTypesPerfMerge`, where the function `merge` has (a slightly more complicated form of) this delicately-balanced situation. But see `Note [Orientation of equalities with fmvs]` in `TcFlatten` for why we don't defer solving (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:43:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:43:08 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.4123fbb42eb9e94542c8d60835df8124@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: warnings, | 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 gkaracha): Yes, I think we can close this :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:44:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:44:07 -0000 Subject: [GHC] #11390: GHC does not warn about redundant patterns In-Reply-To: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> References: <051.57c1ce2ddedf7e2f9a94d134b6a83222@haskell.org> Message-ID: <066.d6e12de5584382f141eadfc32475dd25@haskell.org> #11390: GHC does not warn about redundant patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: warnings, | 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 gkaracha): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 17:55:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 17:55:00 -0000 Subject: [GHC] #11387: Typecasting using type application syntax In-Reply-To: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> References: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> Message-ID: <066.02d1c6a59bcb51e5b069f59c24fc91d1@haskell.org> #11387: Typecasting using type application syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, this is sensible, but I prefer Adam's construction. Yes, the namespace issue is thorny. No, I don't have plans to implement this today. I believe this will be much easier to do after we have `pi` for non-`*`-kinded things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 18:05:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 18:05:01 -0000 Subject: [GHC] #11387: Typecasting using type application syntax In-Reply-To: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> References: <051.27ff0fc90f22019e02342dab25e1f25f@haskell.org> Message-ID: <066.c6aa5a3275b3a44de0e843c9b1849fd8@haskell.org> #11387: Typecasting using type application syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): For one thing, `pi` quantifiers would come in a specific order, while `Typeable` constraints live in a bag of constraints. What would happen if you have multiple types to match on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 18:08:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 18:08:55 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.8afd40c555ffc090a391b55208000922@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): This whole thing is very much a design compromise. It would be fully backward compatible simply to disallow `*` in `TypeInType` code, in favor of `Type`. Of course it's backward compatible, as `TypeInType` is new. But it has a terrible migration story, because you can't use `Type` for `*` in GHC 7.x. So I did a bit of parser hackery to get this to hold together. But it really only works when parsing a normal type. Other places where types appear in unusual situations don't work out so well. (For example, type instance heads and Haskell98 data constructors.) Could this be fixed? I'm sure it could, but it's quite painful each time. I'm quite happy to change designs around this issue. Or for someone to do more parser hackery to get `*` to work in more contexts. This ticket has the same fix as #11307, which is to have new abstract syntax for type instance heads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 18:13:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 18:13:36 -0000 Subject: [GHC] #11360: Test "termination" doesn't pass with reversed uniques In-Reply-To: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> References: <046.51a683cd2d99444ff7e53e945668b5bd@haskell.org> Message-ID: <061.33391fd5874159779d8c19f6f1aa991f@haskell.org> #11360: Test "termination" doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * related: #11360 => #11371 Comment: Sorry, I meant #11371. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 18:39:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 18:39:29 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.82d09d9cc78bf12d999527f8c9f7252a@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by glaubitz): Replying to [comment:5 slyfox]: > Filed a bug upstream to investigate further and/or find a workaround: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69221 Hmm, looks like gcc upstream doesn't agree it's actually a gcc problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 18:42:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 18:42:01 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.80ab2542db5b4761ce4c9b78258e0353@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 alexvieth): Diff created https://phabricator.haskell.org/D1762 A few tests fail due to a changeup in the order of type errors (since instance and tycl decl checking is interleaved). Will need some advice on what to do about that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 18:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 18:57:02 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.4f949b785f964ae83f2ec5deeaf0b0b4@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by rwbarton): Could we, instead of {{{ EF_(raiseExceptionHelper); ... /* exact prototype dectaration, assignment and call: */ { W_ (*ghcFunPtr)(void *, void *, void *); ghcFunPtr = ((W_ (*)(void *, void *, void *))raiseExceptionHelper); }}} generate a local extern function declaration, like {{{ { W_ (*ghcFunPtr)(void *, void *, void *); extern W_ (*raiseExceptionHelper)(void *, void *, void *); ghcFunPtr = ((W_ (*)(void *, void *, void *))raiseExceptionHelper); }}} (sorry if I got the syntax wrong)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 19:02:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 19:02:31 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.ce02971c6e6b7dfe3d83361ea52f3485@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 rwbarton): * priority: normal => highest * milestone: => 8.0.1 Comment: Setting as release blocker since it is a change in behavior in a supposedly Haskell 2010 program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 20:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 20:00:42 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.02a13411129b780691ba58f4dd234ff8@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by mkarcher): rwbarton: The possibility to use a local extern function declaration to avoid the function pointer hack occurred to me, too. I don't know enough about ghc internals to determine whether it is viable. You might try to go without ghcFunPtr, if possible. Like generating {{{ { extern W_ raiseExceptionHelper(void *, void *, void *); raiseExceptionHelper((void*)((W_)BaseReg, (void*)(W_)CurrentTSO, (void*)_c2z);;} }}} instead of {{{ { W_ (*ghcFunPtr)(void *, void *, void *); ghcFunPtr = ((W_ (*)(void *, void *, void *))raiseExceptionHelper); _c2y = ghcFunPtr((void *)(W_)BaseReg, (void *)(W_)CurrentTSO, (void *)_c2z);;} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 20:20:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 20:20:41 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.073b746e783cf069785b528272ef5261@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): I've fixed this (rather simple) problem locally, but it uncovered a deeper one. Consider {{{#!hs x :: forall (v :: Levity) (a :: TYPE v). (?callStack :: CallStack) => a x = undefined }}} Looks innocent enough. But disaster ensues with the generated core, which is like this: {{{ x = \ @(v :: Levity) @(a :: TYPE v) ($dict :: (?callStack :: CallStack)) -> let $dict' = ... in letrec x0 :: a x0 = undefined @v @a $dict' in x0 }}} The problem here is that `x0` is an abomination -- a levity-polymorphic binder, which we have decided are not allowed. This one is harmless (I think), but Core Lint doesn't know that. Any good ideas of how to proceed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 20:28:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 20:28:42 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.e3d21d2933040436a2577ab244698d2b@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Posted my fix to `wip/rae` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 20:29:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 20:29:16 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.2d9df53118ec97fbf70c545dda84f450@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): Phab:D1762 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D1762 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 20:30:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 20:30:38 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.f3761ea43750d396dd1163ade2c82c6d@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): Yeah, I think local extern should work fine (and be cleaner!). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 20:58:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 20:58:16 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.b468d95f6ffc133c3c73dcfac291103e@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 gridaphobe): Is it just a problem because of `x0`, ie would {{{ x = \ @(v :: Levity) @(a :: TYPE v) ($dict :: (?callStack :: CallStack)) -> let $dict' = ... in undefined @v @a $dict' }}} be OK? If so, can we change the desugarer to not generate the intermediate binder when there's only one use and no recursion? I'm not sure that would be a general fix, but it would fix the immediate problem. (Also, why are levity-polymorphic binders not allowed? Is this explained somewhere? Just curious.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 21:49:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 21:49:20 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.6a3facb1a8986801bd3dddbf0e101fa8@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): I agree that we can fix this one problem, but I doubt that it would generalize. I'd like to understand better what's going on here before going down that route. See NoSubKinds (Issues from Dimitrios) for more information about levity- polymorphic binders. The short answer is that we need to know the runtime size of binders, and we don't know this for levity-polymorphic ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 21:52:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 21:52:11 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.e6a1cf58fc5b8672a578a2af45e4bfd3@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 monoidal): Smaller example: {{{ module PairMismatch (f) where f :: a -> [Maybe a] f x = let switch l = [l Nothing, l (Just x)] in switch id }}} While investigating this, I found two more programs that compile with GHC 7.10 but fail with HEAD, I'm not sure if the cause is the same or different. {{{ module PairMismatch2 (f) where u :: a u = u f :: a f = let switch l = l u in switch u }}} {{{ module PairMismatch3 (f) where f :: a f = let switch l = l undefined in switch undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 22:07:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 22:07:44 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.acb219403606ecd9dfb5ecd855d620a1@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): Fair enough. But is the compromise documented in the user manual? Maybe so -- but if not, doing to would be very worth while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 22:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 22:13:05 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators In-Reply-To: <044.2722f1013c64633fbf159145867daa0f@haskell.org> References: <044.2722f1013c64633fbf159145867daa0f@haskell.org> Message-ID: <059.cecfa553129d93e2dc2f2f04c5dec5e7@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 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): Implementing Simon's plan will also fix #11400. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 22:14:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 22:14:07 -0000 Subject: [GHC] #11400: * is not an indexed type family In-Reply-To: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> References: <050.7aa09e167ee4cfb5b7ed39e38e5cef23@haskell.org> Message-ID: <065.f452ef15a4c977c02d9d99039b4f7e1e@haskell.org> #11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 11307 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * blockedby: => 11307 Comment: Will clarify when I write the `TypeInType` documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 22:53:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 22:53:32 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications Message-ID: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int :3:1: error: ? Cannot not apply expression of type ?a0? to a visible type argument ?Int? ? In the expression: 42 @Int In an equation for ?it?: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 23:07:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 23:07:05 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.a90adc02e6e654f82d41f623e8c57305@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 monoidal): This is discussed in the type application paper: https://www.seas.upenn.edu/~sweirich/papers/type-app-extended.pdf, B.4. Overloaded numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 23:18:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 23:18:02 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.c5e229951417fc8c7bf9ecaf02bed0d0@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 rwbarton): Also in ticket:5296#comment:17 and following comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 23:18:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 23:18:32 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.2f77146b73a235e842f0c963fea6fe47@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | TypeApplicaitons 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: => TypeApplicaitons * owner: => goldfire Comment: Thanks for the examples. I think they are artefacts of `TypeApplications`, and the "return-tv" plumbing. Richard and I have a plan for this, which he is going to execute shortly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 23:38:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 23:38:54 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.a5db50162faceff27693ceee657a8f03@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | 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 simonpj): * owner: => goldfire * keywords: => TypeApplications Comment: It'd also be possible to define {{{ integerLit :: Integer -> forall a. Num a => a integerLit n = fromInteger n }}} arrange that `3` elaborates to `integerLit 3` :: forall a. Num a => a`, and now that will work as expected. This is so simple to do that it might be worth doing, just to avoid documenting the infelicity. After all, Haskell advertises that `3 :: forall a. Num a => a`, so it's annoying if it doesn't behave like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 11 23:46:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jan 2016 23:46:12 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.c25dd139df390cedd1d01524a6f5cf70@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | 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 simonpj): * keywords: TypeApplicaitons => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 01:03:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:03:06 -0000 Subject: [GHC] #11410: Quantification over unlifted type variable Message-ID: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> #11410: Quantification over unlifted type variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | 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 silliness is accepted: {{{ data X (a :: TYPE 'Unlifted) = X }}} I will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 01:05:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:05:55 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.7257fa5641c7d441344864d4c3dbb422@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Interestingly, this works on a non-`DEBUG` build, probably because we run Core Lint only after doing the quick optimization pass after desugaring. Perhaps that's a clue to how to solve this... only look for levity- polymorphic binders after the quick optimization pass? Seems a bit odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 01:38:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:38:23 -0000 Subject: [GHC] #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) Message-ID: <050.35a8a152ed237c17a0b1d5e800263285@haskell.org> #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- This should be disallowed, so [https://phabricator.haskell.org/D1757 sayeth goldfire]: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160109: http://www.haskell.org/ghc/ :? for help ?> :set -XKindSignatures ?> import GHC.Types ?> data Wat (a :: TYPE 'Unlifted) = Wat a ?> :i Wat data Wat (a :: #) = Wat a -- Defined at :3:1 ?> :set -XMagicHash ?> :t Wat 1# Wat 1# :: Wat GHC.Prim.Int# ?> :t Wat 'a'# Wat 'a'# :: Wat GHC.Prim.Char# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 01:40:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:40:35 -0000 Subject: [GHC] #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) In-Reply-To: <050.35a8a152ed237c17a0b1d5e800263285@haskell.org> References: <050.35a8a152ed237c17a0b1d5e800263285@haskell.org> Message-ID: <065.547f3d6bed7aec002140dbb111ea2546@haskell.org> #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | 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 rwbarton): Isn't this a duplicate of #11410? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 01:42:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:42:34 -0000 Subject: [GHC] #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) In-Reply-To: <050.35a8a152ed237c17a0b1d5e800263285@haskell.org> References: <050.35a8a152ed237c17a0b1d5e800263285@haskell.org> Message-ID: <065.5cacd2d3f7cd65840c8a1ca3353df4a4@haskell.org> #11411: GHC allows you to quantify variables over TYPE 'Unlifted (a.k.a, #) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #11410 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11410 Comment: Sorry, I missed that one :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 01:46:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:46:26 -0000 Subject: [GHC] #11410: Quantification over unlifted type variable In-Reply-To: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> References: <047.8b584f70bae432ee9b28d295b1649fc4@haskell.org> Message-ID: <062.8a89fd189d100f88bcec7059be625e21@haskell.org> #11410: Quantification over unlifted type variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | 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: | 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 Tue Jan 12 01:47:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 01:47:30 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.21f448badb7e726de209578d3faa6115@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.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 angerman): This has also come up in the `shaking-up-ghc`[1] project, when trying to move the build products out of the source tree[2]. ---- [1]: https://github.com/snowleopard/shaking-up-ghc [2]: https://github.com/snowleopard/shaking-up-ghc/issues/113 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 03:07:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 03:07:14 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.814629f75a69cef4e241ade7479231ca@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Ok, I didnt managed tocut the minimal example out, but I'm on right way, stay tuned! :) I'm writing this comment only to let you know that I remember about it and keep it as an important task and trying to find a little time for it :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 08:48:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 08:48:49 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.1430d39efa49f865d9f8221e2f4d291e@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * related: => #11352 Comment: See also #11352, which is about the same issue for the newfangled overloaded labels (and I guess overloaded string and rational literals should be treated similarly). I experimented with something like Simon's suggestion for overloaded labels, and found that error messages got worse, because it was no longer possible to give a `CtOrigin` that mentioned the overloaded label as the source. But perhaps there's a way round that? Alternatively, I suppose we could add a special rule for typechecking a literal applied to a type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 08:51:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 08:51:18 -0000 Subject: [GHC] #11352: Allow applying type to label In-Reply-To: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> References: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> Message-ID: <066.1253b5a08a074378815256d2fa1f6bce@haskell.org> #11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: ORF 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 adamgundry): * related: => #11409 Comment: See also #11409, the corresponding ticket for numeric literals, in which Simon observes that it's possible to use an auxiliary definition instead of changing the type of `fromLabel`. Although it might still make sense to do the latter, now that we have type application, rather than have a `Proxy#` argument that is unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 10:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 10:01:29 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.71713a35a56f1fdbc731b8774f3ca3dd@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:4 adamgundry]: > See also #11352, which is about the same issue for the newfangled overloaded labels (and I guess overloaded string and rational literals should be treated similarly). OK, so that makes it more worth thinking about. > I experimented with something like Simon's suggestion for overloaded labels, and found that error messages got worse, because it was no longer possible to give a `CtOrigin` that mentioned the overloaded label as the source. I don't understand why. * We continue to have a case in the type checker for integer literals, as now. * It elaborates the literal to `integerLit 3` with type `forall a. Num a => a` When we instantiate that type (which is delayed in the new `TypeApplication` world) we need a suitable `CtOrigin`. We get that using `exprCtOrigin` (see `TcExpr.tcApp`). It can produce a suitable origin for an integer literal, string -- or field label. So it seems ok to me. Worth a try? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 10:04:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 10:04:27 -0000 Subject: [GHC] #4302: Impossible when deriving empty data declaration In-Reply-To: <044.b4e5ca815dec9524c57d94fc3aaed774@haskell.org> References: <044.b4e5ca815dec9524c57d94fc3aaed774@haskell.org> Message-ID: <059.051dc9ce7d4a3758e999eea82ea3734d@haskell.org> #4302: Impossible when deriving empty data declaration -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | deriving/should_compile/T4302 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): commit 2fc5aa708982a414235d3aff68dea4329b546063 {{{ Author: simonpj at microsoft.com Date: Mon Sep 13 17:03:55 2010 +0000 Fix Trac #4302, plus a little refactoring }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 10:05:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 10:05:26 -0000 Subject: [GHC] #4220: EmptyDataDecls + DeriveFunctor == Panic! In-Reply-To: <044.2dbe3c8f74bd13e2369cd4f3232ec68b@haskell.org> References: <044.2dbe3c8f74bd13e2369cd4f3232ec68b@haskell.org> Message-ID: <059.dc99646f13491eecc9237b68c6e3ade8@haskell.org> #4220: EmptyDataDecls + DeriveFunctor == Panic! -------------------------------------+------------------------------------- Reporter: conal | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | deriving/should_compile/T4220 Blocked By: | Blocking: Related Tickets: #4302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #4302 Comment: commit 6efa3901fd6f1583fb654bd3659e88702dfd579a {{{ Author: simonpj at microsoft.com Date: Thu Aug 12 13:13:19 2010 +0000 Fix Trac #4220 For deriving Functor, Foldable, Traversable with empty data cons I just generate a null equation f _ = error "urk" There are probably more lurking (eg Enum) but this will do for now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 11:32:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 11:32:20 -0000 Subject: [GHC] #11352: Allow applying type to label In-Reply-To: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> References: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> Message-ID: <066.8ef9c5f7fd676aa8d2337ca7cc0c0b3c@haskell.org> #11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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 simonpj): * keywords: ORF => ORF, TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 15:30:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 15:30:54 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.56386f9639b6820da702e1f70f2faa16@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Can anyone reproduce this on HEAD or 8.0.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 15:31:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 15:31:35 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.e1c3fe1bafcecbd27744f76c9398be9b@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 15:32:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 15:32:30 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.4478961cbd3fbf1fea6d4f65bf5bd80b@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 15:32:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 15:32:41 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.ce623415cff660a28ed9ece65a16c3d9@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 15:33:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 15:33:23 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.a1b477f3e2cee2327663f58f8c0316dc@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 simonpj): * priority: high => normal * milestone: 8.0.1 => Comment: The right thing is `isDerivedOccName`. I'm working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 15:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 15:33:54 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.0986f834ef3d8f30e7afd8fbe67a6e7f@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 simonpj): * owner: bgamari => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 20:10:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 20:10:10 -0000 Subject: [GHC] #11412: Trouble parsing arithmetic sequence syntax Message-ID: <047.e59f13693e6e7d6f7ac0f7c8833328fb@haskell.org> #11412: Trouble parsing arithmetic sequence syntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The Haskell-98 program {{{#!hs module Bug where blah = [True..] }}} does not compile. I assume this is because GHC thinks that I'm accessing the operator `.` from the module `True`. It took me a little while to figure out what was going on here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 20:24:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 20:24:40 -0000 Subject: [GHC] #10968: Type hole cause bad type checking In-Reply-To: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> References: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> Message-ID: <064.cda6e8f5fc678bdb01db733baba5d44b@haskell.org> #10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11274 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11274 Comment: This is a duplicate of #11274 and others (panic with `-fdefer-typed-holes` and missing instance). Already fixed in 8.0. I don't think adding another test to the testsuite is necessary. For fun, here is a smaller reproducer: {{{ module T10968 where f1 = fmap id _ }}} Thanks for reporting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 20:26:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 20:26:28 -0000 Subject: [GHC] #11412: Trouble parsing arithmetic sequence syntax In-Reply-To: <047.e59f13693e6e7d6f7ac0f7c8833328fb@haskell.org> References: <047.e59f13693e6e7d6f7ac0f7c8833328fb@haskell.org> Message-ID: <062.77089f9874e5c95c7c760ca45a1faefe@haskell.org> #11412: Trouble parsing arithmetic sequence syntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 rwbarton): I have always believed this behavior is specified by the Report, but I've never actually checked that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 20:51:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 20:51:05 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.1d3ffe8a6956181521b6b20f9d295403@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): I definitely think it shouldn't be in the default warning set. I suspect making an "advisory" category is too late for 8.0. But I think keeping -Wredundant-constraints out of -Wall for now is the right thing. Any future refactors of the hierarchy will also still trip it up, so in the future we should probably move it into -Wall and then follow nomeata's suggestion of modifying the policy to be `-Wall -Wno-redundant- constraints` clean. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 20:52:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 20:52:29 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. Message-ID: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, bootstrapping GHC HEAD with HEAD is broken. The failure looks like: {{{ libraries/binary/src/Data/Binary/Builder/Base.hs:67:0: error: missing binary operator before token "(" libraries/binary/src/Data/Binary/Builder/Base.hs:114:0: error: missing binary operator before token "(" libraries/binary/src/Data/Binary/Builder/Base.hs:123:0: error: missing binary operator before token "(" `gcc' failed in phase `C pre-processor'. (Exit code: 1) gmake[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 gmake: *** [all] Error 2 }}} I'm setting highest prio on this (as I feel) so lower this if you like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 21:34:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 21:34:37 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found Message-ID: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: Strict | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE Strict #-} main = print $ let x = undefined in True }}} Using HEAD or GHC 8.0: {{{ $ ghc-8.0.0.20160109 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160109 for x86_64-unknown-linux): StgCmmEnv: variable not found $dIP_aDK local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Using a devel2 build: {{{ $ ./inplace/bin/ghc-stage2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :->] WARNING: file compiler/coreSyn/CoreSubst.hs, line 278 CoreSubst.lookupIdSubst simpleOptExpr $dIP_aDO InScope [aDM :-> a_aDM] WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :-> Once] WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :-> Once] WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160103 for x86_64-unknown-linux): ASSERT failed! file compiler/stgSyn/CoreToStg.hs line 1025 $dIP_aDO 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 Tue Jan 12 22:48:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 22:48:09 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.c3def643f49bcaeb2e117776faa4d62e@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict 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 adamse): Did some very quick testing. At 77ef1a0895b3bfa9236705f4e5ffcd46d6e19ff8 (Dec 14) there is no error: {{{ % ./inplace/bin/ghc-stage2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 22:57:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 22:57:51 -0000 Subject: [GHC] #11415: Pandoc fails to build on 4 GB machine Message-ID: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> #11415: Pandoc fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I made an attempt to install pandoc on laptop with 4 GB RAM and GHC was killed by OS after using all RAM and swap space (512 MB). Output from 'emerge pandoc' http://lpaste.net/148881 I can tolerate slow compile times, however this bug makes it impossible to build some packages which is worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 22:59:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 22:59:03 -0000 Subject: [GHC] #11415: Pandoc fails to build on 4 GB machine In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.b4baa42e117be36949cabcdb6c3f8899@haskell.org> #11415: Pandoc fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pavolzetor): * failure: None/Unknown => GHC doesn't work at all * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 23:04:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 23:04:18 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.2b44cecb6f30adcafb7d7d2f12ad9d49@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * status: new => patch * differential: => Phab:D1767 Comment: The problem with loopification for loops in {{{IO}}} / any monad of the form {{{State# s -> (# State s, a #)}}} is indeed caused by the extra {{{State#}}} tokens. While they have no runtime representation and thus are not passed to a self-recursive call, they are still counted as arguments when considering a self-recursive call for loopification. So I tried to fix this by adding an additional parameter to {{{getCallMethod}}}, namely the number of void arguments, and subtract that number before checking if the correct number of arguments is present (I could not just remove void arguments from the arguments as the number of arguments is used in other places as well and I think there these void arguments have to generate {{{stg_ap_v}}} calls or something similar). I also tried to add a note describing the situation with these void arguments and loopification. I also did a nofib-run. Most things changed only a little bit, but most of the code seems to run a little bit faster, though in praxis it is even less than in my benchmark, but this is not suprising as most code does not (only) consist of such loops in IO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 12 23:06:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jan 2016 23:06:53 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.1b9f2a8ef1a564477e7468a384cdd499@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "nofib-results" added. nofib run comparing current ghc-8.0 branch and my changes applied to it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 02:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 02:18:48 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced Message-ID: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I uncovered this when playing around with `-XTypeInType`: {{{#!hs {-# LANGUAGE DeriveFunctor, TypeInType #-} module CantEtaReduce1 where import Data.Kind type ConstantT a b = a newtype T (f :: * -> *) (a :: ConstantT * f) = T (f a) deriving Functor }}} This fails because it thinks that you can't reduce the last type variable of `T`, since it mentions another type variable (`f`): {{{ ? Cannot eta-reduce to an instance of form instance (...) => Functor (T f) ? In the newtype declaration for ?T }}} But it ''should'' be able to, since `ConstantT * f` reduces to `*`, and the equivalent declaration `newtype T (f :: * -> *) (a :: *) = ...` eta- reduces just fine. I marked this as appearing in GHC 8.1 since you need `-XTypeInType` to have kind synonyms, but this can also happen in earlier GHC versions with data families: {{{#!hs {-# LANGUAGE DeriveFunctor, PolyKinds, TypeFamilies #-} module CantEtaReduce2 where type ConstantT a b = a data family T (f :: * -> *) (a :: *) newtype instance T f (ConstantT a f) = T (f a) deriving Functor }}} I believe the fix will be to apply `coreView` with precision to parts of the code which typecheck `deriving` statements so that these type synonyms are peeled off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 02:22:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 02:22:16 -0000 Subject: [GHC] #11417: Missing context in Generics example Message-ID: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> #11417: Missing context in Generics example -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core | Version: 7.10.3 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 `GHC.Generics` give an example of a default implementation using Generics: {{{#!hs class Encode a where encode :: a -> [Bool] default encode :: (Generic a) => a -> [Bool] encode x = encode' (from x) }}} The default signature is missing some context. It should read {{{#!hs default encode :: (Generic a, Encode' (Rep a)) => a -> [Bool] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 02:23:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 02:23:51 -0000 Subject: [GHC] #11417: Missing context in Generics example In-Reply-To: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> References: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> Message-ID: <060.c1062a22872d59539b7199cd927d488d@haskell.org> #11417: Missing context in Generics example -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 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): I've set a short milestone and high priority because this should be an extremely quick fix. I'd submit the patch myself, but my local copy of the source is outdated and I've forgotten some procedures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 02:43:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 02:43:00 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.8c80d6f831aed1345f74ed6fde8f94bb@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Using unsigned types for size and having random wraparound issues is a huge source of user error in the C++ world, to the point where it is arguably a worse problem than dealing with negative values, since there it is an easy check. On the other hand using a type with undefined overflow once you start dealing with arithmetic and have `x + y - z` situations the logic gets rather complicated and very branchy. The number of branches involved gets even sillier if that type is actually a `Natural` and it has to deal with both small and large code paths behind the scenes. Using `Natural` there would turn such code from two assembly operations and an optional bounds check to something involving up to 16 cases which can't be avoided without getting too clever about it. Like it or not `Int` took on the role of sizes in the Haskell community, and it pushes the bad corner cases far away from the domain of actual use as noted by Reid. I don't see that changing in the foreseeable future. I think I'm going to echo Richard's suggestion of doing this "outside `base`", but without the positive outlook about it being merged back. Switching `KnownNat` to `Natural` and the like is on the agenda, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 06:38:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 06:38:32 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.21e493228e1c1a78da4f69d26e94977e@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by wilx): * cc: vhaisman@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 08:06:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 08:06:03 -0000 Subject: [GHC] #11415: Pandoc fails to build on 4 GB machine In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.6fade16bf59121343ce0f26f8cabd959@haskell.org> #11415: Pandoc fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 08:06:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 08:06:37 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.080c05cf1f6108d4cf24568f1446aef5@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:22:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:22:46 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo Message-ID: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Given these two modules: Aaa.hs: {{{#!hs module Aaa where import BBb main :: IO () main = putStrLn myString }}} Bbb.hs: {{{#!hs module Bbb where myString :: String myString = "hi" }}} There's a typo in `Aaa.hs`, the import should be `Bbb` instead of `BBb`. Running `runhaskell Aaa.hs` results in this error: {{{ Aaa.hs:3:18: Could not find module ?BBb? Use -v to see a list of the files searched for. }}} The request is to have the compiler suggest that this is a typo and that it should be `Bbb` instead. It already does this for misspelled functions, if I recall correctly. Because the compiler will not continue when finding an error like this, it won't be harmful to spend a little extra time looking for possible misspellings. How typo's should be recognized is something that should be fleshed out later. For example, a hamming distance of 2 or less could indicate a typo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:24:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:24:58 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.115ae8e65c7d8c2fdb1e0873d55c6cd4@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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: | -------------------------------------+------------------------------------- Description changed by syd: Old description: > Given these two modules: > > Aaa.hs: > {{{#!hs > module Aaa where > > import BBb > > main :: IO () > main = putStrLn myString > }}} > > Bbb.hs: > {{{#!hs > module Bbb where > > myString :: String > myString = "hi" > }}} > > There's a typo in `Aaa.hs`, the import should be `Bbb` instead of `BBb`. > > Running `runhaskell Aaa.hs` results in this error: > > {{{ > Aaa.hs:3:18: > Could not find module ?BBb? > Use -v to see a list of the files searched for. > }}} > > The request is to have the compiler suggest that this is a typo and that > it should be `Bbb` instead. > It already does this for misspelled functions, if I recall correctly. > > Because the compiler will not continue when finding an error like this, > it won't be harmful to spend a little extra time looking for possible > misspellings. > > How typo's should be recognized is something that should be fleshed out > later. For example, a hamming distance of 2 or less could indicate a > typo. New description: Given these two modules: Aaa.hs: {{{#!hs module Aaa where import BBb main :: IO () main = putStrLn myString }}} Bbb.hs: {{{#!hs module Bbb where myString :: String myString = "hi" }}} There's a typo in `Aaa.hs`, the import should be `Bbb` instead of `BBb`. Running `runhaskell Aaa.hs` results in this error: {{{ Aaa.hs:3:18: Could not find module ?BBb? Use -v to see a list of the files searched for. }}} The request is to have the compiler suggest that this is a typo and that it should be `Bbb` instead. It already does this for misspelled functions, if I recall correctly. Because the compiler will not continue when finding an error like this, it won't be harmful to spend a little extra time looking for possible misspellings. How typo's should be recognized is something that should be fleshed out later. For example, a hamming distance of 2 or less could indicate a typo. I'd like to pick this one up and try to implement it as my first patch to GHC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:31:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:31:03 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.7945fb5125564e78af6bcbe7593cc184@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 nomeata): I think the difference to functions is that with modules, there is no list of modules in scope. And hammering the file system with random guesses is probably a bad idea... It might work for modules that are imported from packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:35:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:35:10 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.4c06b1b5777a3eb20af14cab6b2d25f1@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:2 nomeata]: > I think the difference to functions is that with modules, there is no list of modules in scope. And hammering the file system with random guesses is probably a bad idea... > > It might work for modules that are imported from packages. I haven't really looked into how GHC handles imports to deeply but: Does that mean ghc hammers the file system with guesses for every import? Is there not some sort of cache of previously found modules that we can check? That won't be able to correct every typo but at least every typo for modules that have been compiled already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:36:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:36:33 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.e760e621875879ed960997ae3e57ff9f@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): This is the ticket that added the `-fhelpful-errors` flag (yes you can turn it off with `-fno-helpful-errors`): #2442. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:37:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:37:43 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.fca894cf503bb054313f03e9c1cf4ee1@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 nomeata): > Is there not some sort of cache of previously found modules that we can check? That won't be able to correct every typo but at least every typo for modules that have been compiled already. That might be possible, but such erratic randomness might not give the best user experience. Not sure. I suggest to first implement this (good idea!) for package imports, and when that is done, whoever did it is surely in a good position to assess whether it is feasible for other imports as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:41:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:41:01 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.4dd330754ee4b587c109cddf8c1bd055@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): Replying to [comment:2 nomeata]: > It might work for modules that are imported from packages. Like this you mean? {{{#!hs import Data.Lis }}} {{{ Test.hs:1:8: Could not find module ?Data.Lis? Perhaps you meant Data.List (from base-4.8.2.0) Data.Bits (from base-4.8.2.0) Data.DList (from dlist-0.7.1.2 at 23izrBUDDH96xJKcDju2CZ) Use -v to see a list of the files searched for. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 09:42:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 09:42:11 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.a467ed7aa719edd6c0b052657a30b5ad@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 nomeata): Eh, right. Should have known. Sorry for the noise then :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 12:02:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 12:02:45 -0000 Subject: [GHC] #11415: Pandoc fails to build on 4 GB machine In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.54c4a0b12353824163ef3d11effefbd9@haskell.org> #11415: Pandoc fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 rwbarton): * failure: GHC doesn't work at all => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 12:08:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 12:08:23 -0000 Subject: [GHC] #11415: Pandoc fails to build on 4 GB machine In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.bcb041e2f8ccfd61625ce793d70b39ff@haskell.org> #11415: Pandoc fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 mpickering): This isn't about pandoc. The log you paste doesn't get to even trying to install pandoc. I conjecture that the problem is actually that another dependency (maybe texmath) takes up a lot of memory to compile which causes the OOM to appear when compiling pandoc-types which is relatively simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 12:58:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 12:58:16 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs Message-ID: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Not sure what is going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:06:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:06:23 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.85b6bdc4e62b8f3f3da2b37b901aef34@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"6cb860a9a154847906868ac0be93d750f99dac86/ghc" 6cb860a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6cb860a9a154847906868ac0be93d750f99dac86" Add -prof stack trace to assert Summary: So that assertion failures have full call stack information attached when using `ghc -fexternal-interpreter -prof`. Here's one I just collected by inserting a dummy assert in Happy: ``` *** Exception: Assertion failed CallStack (from ImplicitParams): assert, called at ./First.lhs:37:11 in main:First CallStack (from -prof): First.mkFirst (First.lhs:37:11-27) First.mkFirst (First.lhs:37:11-93) Main.main2.runParserGen.first (Main.lhs:107:48-56) Main.main2.runParserGen.first (Main.lhs:107:27-57) Main.main2.runParserGen (Main.lhs:(96,9)-(276,9)) Main.main2.runParserGen (Main.lhs:(90,9)-(276,10)) Main.main2.runParserGen (Main.lhs:(86,9)-(276,10)) Main.main2.runParserGen (Main.lhs:(85,9)-(276,10)) Main.main2 (Main.lhs:74:20-43) Main.main2 (Main.lhs:(64,9)-(78,61)) Main.main (Main.lhs:57:9-18) ``` Test Plan: validate Reviewers: erikd, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1765 GHC Trac Issues: #11047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:06:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:06:23 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.d85c52a067920d2cb5f235e268ed1f1d@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"3e796e1ae8b13ec1c607a1864894171a58cef592/ghc" 3e796e1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3e796e1ae8b13ec1c607a1864894171a58cef592" A little closer to supporting breakpoints with -fexternal-interpreter Summary: Moves getIdValFromApStack to the server, and removes one use of wormhole. Test Plan: validate Reviewers: bgamari, niteria, austin, hvr, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1768 GHC Trac Issues: #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:15:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:15:46 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.bc2232752299647874bf581712f44b3d@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1769 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:15:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:15:53 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.60631685b6c206f1ce597366910092da@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:16:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:16:07 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.04ada2d638855e143a054ead19234fcf@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When I say > > {{{ > {-# LANGUAGE DataKinds #-} > > module Bug where > > import Data.Typeable > > foo = typeRep (Proxy :: Proxy '[]) > }}} > > I get > > {{{ > GHC error in desugarer lookup in Bug: > Can't find interface-file declaration for variable tc'[] > Probable cause: bug in .hi-boot file, or inconsistent .hi file > Use -ddump-if-trace to get an idea of which file caused the error > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 7.11.20151120 for x86_64-apple-darwin): > initDs IOEnv failure > }}} > > And I think there may be more trouble. Below are notes I have written to > ghc-devs: > > ------------------------------ > > I'm a bit confused by the new handling of `Typeable`. > > 1. You say (in `Note [Grand plan for Typeable]`) that there is trouble > making the `TyCon`/`Module` information for the types in `GHC.Types`. But > what precisely goes wrong? I agree that it seems a bit fishy, but I don't > actually see the spot where trouble lurks. Did you try this? > > 2. Even more bizarre would be putting `TyCon`/`Module` info for > `GHC.Prim` stuff (I'm thinking about the super-magical `TYPE` from my > branch) right in `GHC.Prim`. But still I can't quite articulate what goes > wrong. There is no Prim.hi file that would be wonky. And, provided that > `GHC.Types` itself doesn't try to solve a `Typeable` constraint, no one > would ever notice the weird dependency. I recognize that this means we'd > have to build the info somewhere manually in GHC, but I don't think that > would be too hard -- and I think easier than the current story around > name-mangling just so that you can write the typereps by hand in > `Data.Typeable.Internal`. There's also not very many lifted tycons in > `GHC.Prim`. I count `TYPE` and `RealWorld`, and that's it. > > For what it's worth, a weird dependency from `GHC.Prim` to > `GHC.Types` actually works in practice. I put `Levity` in `GHC.Types` but > `TYPE :: Levity -> TYPE 'Lifted` in `GHC.Prim`. No one complained. > > 3. Let's assume that we really can't clean up this mess. It still seems > that several `TyCon`s are missing from `Data.Typeable.Internal`. Like > promoted nil and cons, and `Nat`, and `Symbol`. At the least, we should > put a loud comment in the export list of `GHC.Types` saying that > everything defined there must be accompanied by a definition in > `Data.Typeable.Internal`. > > 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to > `GHC.Types`. But this function is used also for things from `GHC.Prim`, > like `(->)`. Solving `Typeable (->)` works fine. But I'm sure there's > trouble lurking here. New description: When I say {{{#!hs {-# LANGUAGE DataKinds #-} module Bug where import Data.Typeable foo = typeRep (Proxy :: Proxy '[]) }}} I get {{{ GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151120 for x86_64-apple-darwin): initDs IOEnv failure }}} And I think there may be more trouble. Below are notes I have written to ghc-devs: ------------------------------ I'm a bit confused by the new handling of `Typeable`. 1. You say (in `Note [Grand plan for Typeable]`) that there is trouble making the `TyCon`/`Module` information for the types in `GHC.Types`. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? 2. Even more bizarre would be putting `TyCon`/`Module` info for `GHC.Prim` stuff (I'm thinking about the super-magical `TYPE` from my branch) right in `GHC.Prim`. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that `GHC.Types` itself doesn't try to solve a `Typeable` constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in `Data.Typeable.Internal`. There's also not very many lifted tycons in `GHC.Prim`. I count `TYPE` and `RealWorld`, and that's it. For what it's worth, a weird dependency from `GHC.Prim` to `GHC.Types` actually works in practice. I put `Levity` in `GHC.Types` but `TYPE :: Levity -> TYPE 'Lifted` in `GHC.Prim`. No one complained. 3. Let's assume that we really can't clean up this mess. It still seems that several `TyCon`s are missing from `Data.Typeable.Internal`. Like promoted nil and cons, and `Nat`, and `Symbol`. At the least, we should put a loud comment in the export list of `GHC.Types` saying that everything defined there must be accompanied by a definition in `Data.Typeable.Internal`. 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types`. But this function is used also for things from `GHC.Prim`, like `(->)`. Solving `Typeable (->)` works fine. But I'm sure there's trouble lurking here. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:25:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:25:56 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.e2637a8a1d82e159b5c89aa1e9e41702@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by bgamari): erikd, I believe this has been resolved. Perhaps you could verify this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:26:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:26:47 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.ad3faae0509cebf9553ba4db3668c7dd@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by bgamari): I believe this is now fixed. Perhaps someone could confirm this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:30:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:30:35 -0000 Subject: [GHC] #10969: Arm: Investigate Thumb2/Arm interworking In-Reply-To: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> References: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> Message-ID: <059.9f4e1e817b553fec0b734fe19321ed7d@haskell.org> #10969: Arm: Investigate Thumb2/Arm interworking ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (CodeGen) | Version: 7.11 Resolution: fixed | Keywords: arm, thumb Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10375 | Differential Rev(s): Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: I believe we can consider this fixed. The current situation is that GHC produces strictly ARM code, avoiding the need to handle interworking between Haskell functions (which is quite tricky due to tables-next-to- code). However, we can now call foreign Thumb functions without any trouble due to a variety of linker fixes (which are collected on #11206). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:31:13 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.46b29989ad9c00bff977b7a5c9eedd5d@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I think it is safe to say that this is resolved. My nightly builds have been quite stable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:32:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:32:52 -0000 Subject: [GHC] #9048: armel: evacuate(static): strange closure type 0 In-Reply-To: <046.ccacb8854bad97b5f58adb6faa140591@haskell.org> References: <046.ccacb8854bad97b5f58adb6faa140591@haskell.org> Message-ID: <061.5ae221595ed575b44e99516739211149@haskell.org> #9048: armel: evacuate(static): strange closure type 0 ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: I believe this ought to now be fixed after a number of fixes in 8.0. See #11206 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:34:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:34:16 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install In-Reply-To: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> References: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> Message-ID: <063.712c3cfb6bba6ffab47532f3cffc0d9f@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ----------------------------------+------------------------------ Reporter: muhmuhten | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by bgamari): * status: infoneeded => closed * resolution: => worksforme * milestone: 7.10.3 => 8.0.1 Comment: This should be fixed in 8.0.1 if not 7.10.3 due to the fixes documented in #11206. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:34:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:34:28 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install In-Reply-To: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> References: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> Message-ID: <063.c8119f63b35a105f7c1b7e094b7ed552@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ----------------------------------+------------------------------ Reporter: muhmuhten | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by bgamari): * status: closed => new * resolution: worksforme => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 13:34:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:34:33 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install In-Reply-To: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> References: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> Message-ID: <063.5c8feb5feadf4b0e801b6198854c5bae@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ----------------------------------+------------------------------ Reporter: muhmuhten | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | 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 Jan 13 13:35:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 13:35:04 -0000 Subject: [GHC] #11415: pandoc-types fails to build on 4 GB machine (was: Pandoc fails to build on 4 GB machine) In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.a99c99bf6a8436367992b21e286ffe22@haskell.org> #11415: pandoc-types fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 rwbarton): Actually the module `Text.Pandoc.Definition` is just expensive to build. For me (GHC 7.8.4) it takes about 25 seconds and 460M to build with optimizations. 7.10.1 fares significantly worse, about double on both metrics. (I think it is doing more inlining.) The main culprit seems to be the `FromJSON`/`ToJSON` which use generics. Commenting those out reduces the runtime by a factor of ~5 and the memory usage by a factor of ~3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:22:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:22:18 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.0ae3968559dc8c4d889e89e42fca794c@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d44bc5c061e3f0ba459f835aba683c0366187b74/ghc" d44bc5c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d44bc5c061e3f0ba459f835aba683c0366187b74" TemplateHaskell: revive isStrict, notStrict and unpacked These 3 functions are useful to keep around a bit longer, to prevent breaking existing code that uses them. Related to #10697. Reviewers: austin, goldfire, RyanGlScott, bgamari Reviewed By: RyanGlScott, bgamari Differential Revision: https://phabricator.haskell.org/D1761 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:22:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:22:18 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.7f16b813f8257be60310a6e48cd7ac76@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ac3cf68c378410724973e64be7198bb8720a6809/ghc" ac3cf68/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ac3cf68c378410724973e64be7198bb8720a6809" Add missing type representations Previously we were missing `Typeable` representations for several wired-in types (and their promoted constructors). These include, * `Nat` * `Symbol` * `':` * `'[]` Moreover, some constructors were incorrectly identified as being defined in `GHC.Types` whereas they were in fact defined in `GHC.Prim`. Ultimately this is just a temporary band-aid as there is general agreement that we should eliminate the manual definition of these representations entirely. Test Plan: Validate Reviewers: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1769 GHC Trac Issues: #11120 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:22:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:22:18 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.f3d3a2cde82f3260d940cc5927d9be08@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e782e882ba455c671cb35751053822a74a9f66b7/ghc" e782e88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e782e882ba455c671cb35751053822a74a9f66b7" Add test for Data.Typeable.typeOf Test Plan: Validate Reviewers: goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1770 GHC Trac Issues: #11120 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:22:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:22:18 -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.01c889e7bb4cd143d8f31e72e70cf073@haskell.org> #11389: Print a message when loading a .ghci file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kseo Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 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 Ben Gamari ): In [changeset:"c3f92464bf64dacae76dc9b3566df9a9f6b3a85b/ghc" c3f92464/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c3f92464bf64dacae76dc9b3566df9a9f6b3a85b" Print a message when loading a .ghci file. Test Plan: ./validate Reviewers: austin, thomie, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1756 GHC Trac Issues: #11389 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:39:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:39:14 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.d7970272e2aacabde1eda2e61c196073@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Commit is good. But we should keep this ticket open, or open a new one, to do this in a better way. There is much in comment:3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:40:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:40:23 -0000 Subject: [GHC] #11415: pandoc-types fails to build on 4 GB machine In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.5fdfe20b2f5edd6b3625e076942e7a21@haskell.org> #11415: pandoc-types fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Generics 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): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:49:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:49:18 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.05467485b14879845ae26bf1ab919fb9@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407, #11100 | Phab:D1595, Phab:D1747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Would it be possible to comment the new code in `assertError`? Why `unsafeDupablePerformIO`? What's the goal? What happens in the non- profiling case? That would help people working on this in the future. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 14:57:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 14:57:24 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.568c90ae784a5fce6fb24b940f66e45b@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This might have been mentioned already (hard to tell, since I don't really understand the technical details here), but it's still possible to trigger GHC panics pretty easily due to (what I assume are) inadequate type representations: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160113: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /nfs/nfs4/home/rgscott/.ghci ?> :set -XTypeInType -XMagicHash ?> :m + Data.Typeable GHC.Prim GHC.Exts ?> data CharHash = CharHash Char# ?> typeOf (Proxy :: Proxy 'CharHash) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160109 for x86_64-unknown-linux): tyConRep Char# Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ?> typeOf (Proxy :: Proxy 'C#) GHC error in desugarer lookup in Ghci2: Can't find interface-file declaration for variable tc'C# Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160109 for x86_64-unknown-linux): initDs IOEnv failure 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 Wed Jan 13 15:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 15:28:55 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced In-Reply-To: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> References: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> Message-ID: <065.375b5020ded3e54b5a030a5e02c7732e@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): Phab:D1772 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1772 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 15:29:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 15:29:56 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.72183f38a42b37663fa0849c6fd4d54a@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc1 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): Phab:D1744, Wiki Page: | Phab:D1766 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D1744 => Phab:D1744, Phab:D1766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 15:33:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 15:33:55 -0000 Subject: [GHC] #11420: Incorrect links Message-ID: <043.892271951d8342b4b169aedd748e7403@haskell.org> #11420: Incorrect links -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 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 links to the source tarballs on the page https://www.haskell.org/ghc/download_ghc_7_10_3 are incorrect. Instead of links to the source tarballs, the links to the sources of windows-extra are provided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 15:39:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 15:39:25 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.6ab09647a27f9d0ba8d9f1c724fa33db@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Richard and I talked about this yesterday. Our provisional solution is to make `tcPolyCheck` produce a new, simpler form of `AbsBinds` whose desugaring too can be simpler. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 15:40:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 15:40:58 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.76862849e97ca8ee53647145b7e7b9d2@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 16:46:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 16:46:04 -0000 Subject: [GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure Message-ID: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See attached file. I think both type signatures for xs should work. The ghci error unfortunately doesn't show up on :reload, but it shows up when trying to run an unrelated function (main here). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 16:46:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 16:46:19 -0000 Subject: [GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure In-Reply-To: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> References: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> Message-ID: <060.f8be18a70c8dcc2b00e7e919a363c068@haskell.org> #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 aavogt): * Attachment "err.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 17:44:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 17:44:22 -0000 Subject: [GHC] #11412: Trouble parsing arithmetic sequence syntax In-Reply-To: <047.e59f13693e6e7d6f7ac0f7c8833328fb@haskell.org> References: <047.e59f13693e6e7d6f7ac0f7c8833328fb@haskell.org> Message-ID: <062.73474554385edf59927a9407ed099ecc@haskell.org> #11412: Trouble parsing arithmetic sequence syntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): * status: new => closed * resolution: => invalid Comment: Bah. You're right. It still is confusing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 18:52:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 18:52:14 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.59266bf85cc5a34bfad02620b54901c8@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: diatchki Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): That's odd, there is very explicit code that is supposed to handle these case... I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:24:18 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.d1c573aa458c6c771bf8eb408130142d@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:21 simonmar]: > > OK. So the in the dynamic case GHCi SHOULD NOT (MUST NOT?) require the presence of the development versions of C libraries when using an installed Haskell package. This is currently not the case. > > I think we could make it so that GHCi, if using dynamic libraries, doesn't require the `-dev` version of C library dependencies, but what's the gain from doing that? GHC would still require it when not using `-dynamic`, so you wouldn't be able to omit the dependency on `-dev` in the distro packages, for example. No, if we implemented my proposal in comment:16 we would not need the dependency on C library `-dev` packages anymore. The `-dev` package would only be a build requirement. This makes a difference on openSUSE's build service where we build each package in a separate virtual machine and install only packages that are actually needed for the current build. So when we __use__ the such a package in another build we would not have to install the C `-dev` packages and some of those can be fairly large. Moreover, we could get rid of the code chasing C libraries in `Linker.hs` and remove the code that parses linker scripts in `rts/Linker.c`. #9237 fails because the parsing of linker scripts is incomplete. #10046 might be an issue with linker scripts, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:32:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:32:36 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.053f66561617ea101982a75d6486daef@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: diatchki Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): OK, it was a pretty simple fix---I just pushed the correction to master. The problem was that when I was looking for `TypeError` in a type, I forgot that it may be "over applied", because it could be used at kinds like`Type -> Type`. I added a comment to `userTypeError_maybe` so we don't forget about this in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:35:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:35:04 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.f47e47a345ee99577405340b3f084b90@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This has been merged to `ghc-8.0` as 0f2cb663e47e5912e1694efe50d94d16bce63902. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:35:34 -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.62692a217c2b972108815a4e9d1509c7@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This has also been merged to `ghc-8.0` as 45c4cc1e408e1fee5217fae2bdb01f279122d7d5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:38:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:38:17 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.54eab8b6fa65b1c85185fc91c901872d@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've merged `TemplateHaskell: revive isStrict, notStrict and unpacked` to `ghc-8.0` as b8d32e2f620d4f70bc3fffb791676b3a56ca26bd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:41:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:41:37 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.4397a62955084ed9dde03dafe03a7862@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1773 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: => Phab:D1773 Comment: Good spot as always @awson! I've put it up on Phabricator for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:43:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:43:21 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.06fd67947039a90e7bd21ba24937d670@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, yes, I suppose we need to handle everything in `GHC.Prim` as well. If we include all of the generated SIMD types this adds up to a substantial amount of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:53:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:53:52 -0000 Subject: [GHC] #11422: outofmem RTS testcase fails on Windows Message-ID: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> #11422: outofmem RTS testcase fails on Windows ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: outpfmem | Blocked By: Blocking: | Related Tickets: #11300 Differential Rev(s): Phab:D1753 | Wiki Page: ----------------------------------------+--------------------------------- The `outofmem` test case fails on Windows `x86` and `x86_64` with the wrong exit code. Expected `251` but gotten `1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 19:54:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 19:54:46 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.1005ec2fbb4dd3ce3081d13e146d5982@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11422 | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by Phyx-): * differential: Phab:D1753 => * related: => #11422 Comment: Created a new issue for the Windows failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 20:23:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 20:23:44 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.9b2292d5767a72cb5062316a50557fcc@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1773 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Thanks! In fact, this is critical to make `-fsplit-sections` on Windows work (but this requires to use HEAD binutils and also to patch a couple of bugs there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 21:42:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 21:42:29 -0000 Subject: [GHC] #11423: GHC 8.0-rc1's linker does not work in OSX Message-ID: <046.4d046600b2eefbe174b22f5b5b3bb063@haskell.org> #11423: GHC 8.0-rc1's linker does not work in OSX ----------------------------------------+--------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: ----------------------------------------+--------------------------------- Hello! When I try to run `cabal install data-default` (it is just a very small library) I get the following output using GHC 8.0-rc1: {{{ cabal install data-default Resolving dependencies... Notice: installing into a sandbox located at /Users//dev/hs/env/default8/.cabal-sandbox Configuring data-default-class-0.0.1... Configuring dlist-0.7.1.2... Configuring old-locale-1.0.0.7... Failed to install data-default-class-0.0.1 Build log ( /Users//dev/hs/env/default8/.cabal-sandbox/logs/data- default-class-0.0.1.log ): Failed to install dlist-0.7.1.2 Build log ( /Users//dev/hs/env/default8/.cabal- sandbox/logs/dlist-0.7.1.2.log ): Failed to install old-locale-1.0.0.7 Build log ( /Users//dev/hs/env/default8/.cabal-sandbox/logs/old- locale-1.0.0.7.log ): cabal: Error: some packages failed to install: data-default-0.5.3 depends on old-locale-1.0.0.7 which failed to install. data-default-class-0.0.1 failed during the configure step. The exception was: user error ('/opt/ghc/8.0-rc1/bin/ghc' exited with an error: ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) ) data-default-instances-base-0.0.1 depends on data-default-class-0.0.1 which failed to install. data-default-instances-containers-0.0.1 depends on data-default- class-0.0.1 which failed to install. data-default-instances-dlist-0.0.1 depends on dlist-0.7.1.2 which failed to install. data-default-instances-old-locale-0.0.1 depends on old-locale-1.0.0.7 which failed to install. dlist-0.7.1.2 failed during the configure step. The exception was: user error ('/opt/ghc/8.0-rc1/bin/ghc' exited with an error: ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) ) old-locale-1.0.0.7 failed during the configure step. The exception was: user error ('/opt/ghc/8.0-rc1/bin/ghc' exited with an error: ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 21:44:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 21:44:08 -0000 Subject: [GHC] #8613: simplifier ticks exhausted In-Reply-To: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> References: <044.3c96d4abc261f1969033a0de42af80e6@haskell.org> Message-ID: <059.25fb9769ba28c9dba097a7e0e03a03cb@haskell.org> #8613: simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | 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 thomie): * status: new => closed * resolution: => worksforme Comment: GHC 7.10 actually started accepting this program again, with the default `simpl-tick-factor` program, but GHC 8.0 doesn't. ||||||= `-fsimpl-tick-factor` =|| ||= GHC =||= panic =||= ok =|| || 7.10 || 90 || 95 || || 8.0.1 || 110 || 115 || This doesn't seem like a GHC bug. Either increase the tick factor a bit when compiling this program, or remove some of the `INLINE`s. Thanks for reporting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 22:00:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 22:00:34 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.fba09f39a2a3128e7a52c30938490a61@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: diatchki Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great work Iavor, thanks. Always mention the ticket in the commit message! Then the ticket appears in the Trac ticket automatically. Also, could you add a regression test pls? (And update the "Test Case" field of the ticket appropriately.) Manually, the commit is {{{ commit 6ea24af9f22f6ea661d79623135f4cd31e28c6a2 Author: Iavor S. Diatchki Date: Wed Jan 13 11:30:40 2016 -0800 Handle over-applied custom type errors too. Consider type family F :: Type -> Type where F = TypeError (Text "Error") Now, if we see something like `F Int` we should still report the custom type error. >--------------------------------------------------------------- 6ea24af9f22f6ea661d79623135f4cd31e28c6a2 compiler/typecheck/TcRnTypes.hs | 6 +++--- compiler/types/Type.hs | 5 ++++- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/compiler/typecheck/TcRnTypes.hs b/compiler/typecheck/TcRnTypes.hs index 6beff7f..430a97d 100644 --- a/compiler/typecheck/TcRnTypes.hs +++ b/compiler/typecheck/TcRnTypes.hs @@ -1733,9 +1733,9 @@ isTypeHoleCt (CHoleCan { cc_hole = TypeHole }) = True isTypeHoleCt _ = False -- | The following constraints are considered to be a custom type error: --- 1. TypeError msg --- 2. TypeError msg ~ Something (and the other way around) --- 3. C (TypeError msg) (for any parameter of class constraint) +-- 1. TypeError msg a b c +-- 2. TypeError msg a b c ~ Something (and the other way around) +-- 4. C (TypeError msg a b c) (for any parameter of class constraint) getUserTypeErrorMsg :: Ct -> Maybe Type getUserTypeErrorMsg ct | Just (_,t1,t2) <- getEqPredTys_maybe ctT = oneOf [t1,t2] diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index 6a86f70..c727da6 100644 --- a/compiler/types/Type.hs +++ b/compiler/types/Type.hs @@ -707,7 +707,10 @@ isStrLitTy _ = Nothing -- If so, give us the kind and the error message. userTypeError_maybe :: Type -> Maybe Type userTypeError_maybe t - = do { (tc, [_kind, msg]) <- splitTyConApp_maybe t + = do { (tc, _kind : msg : _) <- splitTyConApp_maybe t + -- There may be more than 2 arguments, if the type error is + -- used as a type constructor (e.g. at kind `Type -> Type`). + ; guard (tyConName tc == errorMessageTypeErrorFamName) ; return msg } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 13 22:29:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jan 2016 22:29:35 -0000 Subject: [GHC] #11417: Missing context in Generics example In-Reply-To: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> References: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> Message-ID: <060.cd40a5d25c4628e1fce254ec7e529833@haskell.org> #11417: Missing context in Generics example -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 00:10:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 00:10:28 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.1b550b5c390772b31388c391f33a2343@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1776 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D1776 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 00:33:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 00:33:07 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families Message-ID: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- Hello, consider the following example: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family Same a b where Same a a = Int Same a b = Char example :: Same a [a] -> a example = undefined bad :: a bad = example 'c' }}} This program should type check, using the following reasoning: `a` and `[a]` can never be equal, therefore the first equation for `Same` does not apply, and so we can fall trough to the second one, thus reducing `Same` to `Char`. Therefore, `bad` should be accept. GHC rejects this program with the following error: {{{ ? Couldn't match expected type ?Same a [a]? with actual type ?Char? ? In the first argument of ?example?, namely ?'c'? In the expression: example 'c' In an equation for ?bad?: bad = example 'c' ? Relevant bindings include bad :: a (bound at tmp/test.hs:11:1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 02:52:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 02:52:29 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.2483a16e8f5ec348bc53db9bfbd3f960@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 09:02:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 09:02:20 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.1d70ec16da2480f4b6f29c213e107bc6@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 simonpj): What if 'a' was instantiated with `Loopy Int` where {{{ type family Loop x type instance Loopy Int = [Loopy Int] }}} Now indeed if we see `Same (Loopy Int) [Loopy Int]` we could reduce it to `Int`. This is all very tiresome I know. It's discussed at some length in our "Closed type families" paper. If you can think of a better solution than what we propose there, we're all ears. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 09:11:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 09:11:37 -0000 Subject: [GHC] #7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces In-Reply-To: <045.42daa80bec50ee64f583a1fc00a7a95b@haskell.org> References: <045.42daa80bec50ee64f583a1fc00a7a95b@haskell.org> Message-ID: <060.342420428238ca4e7a437928f3d439fd@haskell.org> #7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.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 edsko): This still applies to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 09:11:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 09:11:54 -0000 Subject: [GHC] #7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces In-Reply-To: <045.42daa80bec50ee64f583a1fc00a7a95b@haskell.org> References: <045.42daa80bec50ee64f583a1fc00a7a95b@haskell.org> Message-ID: <060.230d954b9f9c32ddd8f1879a00a19a62@haskell.org> #7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.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 edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 09:39:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 09:39:04 -0000 Subject: [GHC] #11423: GHC 8.0-rc1's linker does not work in OSX In-Reply-To: <046.4d046600b2eefbe174b22f5b5b3bb063@haskell.org> References: <046.4d046600b2eefbe174b22f5b5b3bb063@haskell.org> Message-ID: <061.eb225be787559a39f85a18f6eb396caf@haskell.org> #11423: GHC 8.0-rc1's linker does not work in OSX ---------------------------------+---------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): * milestone: => 8.0.1 Comment: Hrm, indeed this was due to out-of-date [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX|build instructions] on the Wiki, resulting in a build that was dynamically linked against `libgmp`. I've fixed the instructions but haven't yet had time to do another build. I'll try to get this done today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 09:42:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 09:42:52 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.60ec5e6f1d9c0726037e608966fbe131@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Changes (by bgamari): * priority: high => highest Comment: People have privately indicated to me that this is affecting them and it would be nice to see it fixed for 8.0.1. Given that the patch apparently validates on OS X, perhaps we should consider merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 10:12:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 10:12:03 -0000 Subject: [GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling Message-ID: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> #11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.2.1 Component: GHC API | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tools like ghc-mod typically just want `TypecheckedModule`s. Sadly, the GHC API currently doesn't provide a good way to get at these in all cases (see this [https://github.com/DanielG/ghc-mod/issues/205|ghc-mod ticket]). Each of the options we offer are cursed with their own limitations (largely quoting from the ghc-mod ticket), == HscNothing == At first glance this looks like what you would want. But... * Pros * Doesn't generate code of any sort and is therefore rather lightweight * Cons * It lacks support for Template Haskell * Has trouble with `foreign export`s * [https://github.com/DanielG/ghc-mod/pull/145|Fails} to issue pattern match checker warnings == HscInterpreted == Okay, so `HscNothing` doesn't work. Maybe `HscInterpreted` is better? * Pros * Supports Template Haskell * Cons * Can't deal with unboxed tuples (#1257) * Slower as we need to produce unnecessary bytecode * Large memory footprint * Also can't deal with `foreign export`s == HscAsm == * Pros * Supports all compilable code * Cons * Slow * Produces `.o` files This is quite unfortunate. It seems like we need something in between `HscNothing` and `HscInterpreted` which is willing to use the interpreter to evaluate Template Haskell splices when necessary, but doesn't produce bytecode. Unfortunately it's unclear what to do about `foreign export` (but arguably most tools would be fine with some approximate representation). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 10:43:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 10:43:12 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.c5208f5b2d15251a0c50f06e4c385ce2@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1776 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:16:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:16:21 -0000 Subject: [GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling In-Reply-To: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> References: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> Message-ID: <061.544ba0a4072b423844ce168953efa4b7@haskell.org> #11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: GHC API | Version: 7.10.3 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 alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:17:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:17:38 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.7674b980ba906f858addaabb29fb96ff@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Changes (by trommler): * status: new => patch Comment: The patch is ready for merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:22:11 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.90bd19bacbe5474b6df576e855d14b07@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): * priority: normal => highest Comment: We should really try to get to this for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:33:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:33:04 -0000 Subject: [GHC] #11382: Optimize Data.Char In-Reply-To: <046.07b85d059cbd81601867717299b83062@haskell.org> References: <046.07b85d059cbd81601867717299b83062@haskell.org> Message-ID: <061.38ce6e309bb1eaddea40b989cd852bd0@haskell.org> #11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9638 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the reference, thomie. It looks like David has done some good work in this area already. This is an area where improvements in branchless boolean operations (#9661) may help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:33:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:33:52 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.524c3e5e6b81c2d254e8bcae6ef94130@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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): D854 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The operations in `Data.Char` may stand to benefit from less branchy code generation. See #11382 and #9638. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:35:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:35:09 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.af0b4570ee73dd2b1c16df9e7b30e288@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11382 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * related: => #11382 Comment: It seems that David's commit has addressed the principle complaint of this ticket. We can track further improvements in #11382. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:43:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:43:52 -0000 Subject: [GHC] #11417: Missing context in Generics example In-Reply-To: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> References: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> Message-ID: <060.893cafda8b6d4cff0e8d7f9480ee3f45@haskell.org> #11417: Missing context in Generics example -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 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 Ben Gamari ): In [changeset:"91dcc655932b7977c9901d3504bc3d8f0ca8cb6e/ghc" 91dcc65/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91dcc655932b7977c9901d3504bc3d8f0ca8cb6e" GHC.Generics: Fix documentation Fixes #11417. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:43:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:43:52 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.7d9c5b64a62a80f5ae406dfd7b6593cd@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: diatchki Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0c4e460ee0dad372d5b896a03cdac9666026174/ghc" f0c4e46/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0c4e460ee0dad372d5b896a03cdac9666026174" Add tests for #11391 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:48:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:48:48 -0000 Subject: [GHC] #11381: Put injective type families in a separate language extension In-Reply-To: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> References: <048.e1efd6da86372c1cceaa5800f2a467f6@haskell.org> Message-ID: <063.1d314add06d3fc1afbc93b409dbdd174@haskell.org> #11381: Put injective type families in a separate language extension -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: TypeFamilies, | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T11381 Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1750 Wiki Page: | -------------------------------------+------------------------------------- Old description: > Injective type families should only be enabled when language extension > `InjectiveTypeFamilies` is specified. This extension should imply > `TypeFamilies`. New description: Injective type families should only be enabled when language extension `TypeFamilyDependencies` is specified. This extension should imply `TypeFamilies`. -- Comment (by bgamari): It was ultimately decided that the extension name should be generalized to `TypeFamilyDependencies`. This renaming was performed in, {{{ commit 78a4c729ecb07c92822625fda15f14a778679452 Author: Ben Gamari Date: Thu Jan 14 11:52:10 2016 +0100 Rename InjectiveTypeFamilies to TypeFamilyDependencies }}} This has been merged to `ghc-8.0` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:51:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:51:19 -0000 Subject: [GHC] #11391: TypeError is fragile In-Reply-To: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> References: <046.7b64429232b32f90bcee7d67f48f09b8@haskell.org> Message-ID: <061.0d9c1e33d4273ecfe7ba39ec4201c400@haskell.org> #11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: diatchki Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 11:52:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 11:52:08 -0000 Subject: [GHC] #11417: Missing context in Generics example In-Reply-To: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> References: <045.73f7e504f80257378bf909618fb01eaa@haskell.org> Message-ID: <060.8d4daf60109f16fdb300e846a2a915e7@haskell.org> #11417: Missing context in Generics example -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I've merged this into `master` and `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 12:23:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 12:23:37 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.7492a35f13a3a416656e0e321ef96975@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: fixed => Comment: I didn't understand Duncan's "ulterior motives" before, but since he just mentioned them on IRC, I'm rather sure they are wrong. We should create a `MIN_VERSION_*` macro for every ''visible'' package. Cabal builds with `-hide-all-packages` anyways, so this is no behavior change compared to what's currently implemented when building with Cabal. The performance worry seems suspect, too. Besides the fact that Cabal builds are still unaffected, the amount of work needed to write out the header file can't be large in comparison to the time needed to read the package database in the first place. The only non-linear case would be using `ghc --make` to build a large number of modules while having a large number of packages in the package database, when cpp would have to process the header file once for every package. I think this is still unlikely to be a big issue compared to ghc actually compiling the modules. I'll try to do some timing tests. On general principle, it seems bad to unnecessarily create multiple "tiers" of visible packages: the visible packages but also the ''really'' visible packages, that were specified explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 12:29:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 12:29:54 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.465e4ffd1ac7c078440a2b4c58d4ae70@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 Comment: Uh oh. Note that the version in question here is 8.0.1, not 8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 12:30:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 12:30:04 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.c516b5e8aced7b94b6ea97e28740cfe6@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 13:01:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 13:01:22 -0000 Subject: [GHC] #11426: API Annotations: Detached parens annotations for infix function Message-ID: <044.928798e8b8b7ccfd94c10d014532354b@haskell.org> #11426: API Annotations: Detached parens annotations for infix function -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code {{{#!hs module ParenFunBind where (foo x) y = x + y }}} results in the annotations for the `(` and `)` not being attached to anything in the final `ParsedSource` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 13:04:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 13:04:41 -0000 Subject: [GHC] #11426: API Annotations: Detached parens annotations for infix function In-Reply-To: <044.928798e8b8b7ccfd94c10d014532354b@haskell.org> References: <044.928798e8b8b7ccfd94c10d014532354b@haskell.org> Message-ID: <059.e300acc4288a1cc12f6e9a3bc7fd76d9@haskell.org> #11426: API Annotations: Detached parens annotations for infix function -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 13:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 13:21:31 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.fa0258d6b7b63f41e7655fcb16cf7ac7@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I made a header file with 100000 copies (with different names) of the two macros generated per package, and ran a file that `#include`s it through cpp. It took 0.27 seconds. So for a more realistic package database size of 1000 packages, that's 2 milliseconds. I think that overhead is negligible relative to the time it takes ghc to compile any module. Not critical to fix this for 8.0 though, since it's just a convenience feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 14:12:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 14:12:16 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.ff69b38e848d26f54146220449b2d98d@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek 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): * differential: => Phab:D1778 * wikipage: => GhcKinds/KindsWithoutData -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 14:56:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 14:56:20 -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.466fe734b1fad9242fff86150b631a8b@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 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-): I think Joey's IOCP based manager from #11394 could be a good start for this. We should see how easy it is to bring his old code up to date on GHC now and how much of it can be re-used https://github.com/joeyadams/haskell- iocp Might also want to consider support for Registered I/O which would significantly up the throughput for Windows Based server programs. It's a recent addition to Windows 8+, but might be worth a look at https://technet.microsoft.com/en-us/library/hh997032.aspx. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 15:42:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 15:42:16 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.c94bd8ee157a57539c26f6e1cb17975c@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I think you're right: my problems before arose because I was replacing the overloaded label with the function application in the typechecker, rather than preserving it until the desugarer. Hence `exprCtOrigin` saw the wrong thing. On another topic, what about `RebindableSyntax`? At the moment we have (according to the manual): > An integer literal `368` means "`fromInteger (368::Integer)`", rather than "`Prelude.fromInteger (368::Integer)`". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 16:39:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 16:39:29 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced Message-ID: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance #if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} #endif All SListI xss => SingI (xss :: [[k]]) where sing = sList }}} fails with {{{ ? Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at src/Generics/SOP/Constraint.hs:141:3-40 ? In the instance declaration for ?SingI xss? }}} See https://travis-ci.org/well-typed/generics-sop/jobs/102388817 and https://github.com/phadej/generics-sop/tree/ghc-8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 16:54:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 16:54:28 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.9647266bd7d620ed0dcd65dd1e51c7b2@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek 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 | -------------------------------------+------------------------------------- Comment (by jstolarek): Two design questions: 1. This work should obviously go into its own language extension. How should we name it? Note that it will enable not only open data kinds, but also closed data kinds without associated data type (#6024) 2. Should the new extension imply any other extensions? I think `PolyKinds` should be implied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 17:25:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 17:25:01 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.5a10a6e85cc14750824041e1fdf47f2f@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by quchen): I agree with Simon that things like redundant constraints are not "probably broken" (warnings) or broken (errors). I'm a big fan of compilers educating users to best practices (advisories), and redundant constraints fall into this category. It's as bad as trailing whitespace, literal tabs, or redundant parentheses. That said, I think we need a more strict "-Wall", I named it "-WALL" for the lack of a better name (-Wpedantic akin to GCC would also work, or -Wlint) where we enable such suggestions. This flag would be useful for building-and-fixing once-ish per release, and would make no compatibility guarantees. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 17:29:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 17:29:50 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.2ed9a9b9e62dae0b92c3c23c3c2cdd0b@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > No, if we implemented my proposal in comment:16 we would not need the dependency on C library -dev packages anymore. The -dev package would only be a build requirement. I think maybe we're talking about different things, let me try to clarify. * If you install a Haskell package to be used with GHC, you still need the `-dev` version of any C library dependencies. That's independent of your proposal in comment:16, because we need the -dev libraries when building standalone executables. * If you install a package because it is a runtime dependency of an executable or another library, then you don't need the -dev version of C dependencies. So you could, if you wanted, split compiled Haskell packages into dev and non-dev distributions. * The case you seem to be referring to is somewhere between these two, where you're only using a package in GHCi, or only via the GHC API. In those cases you could avoid needing the `-dev` dependency, but I'm not sure how you would distinguish this kind of dependency. How can you tell that the user isn't going to try to use GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 18:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 18:02:18 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.1aafe5a0fcba71a22d644051b4c878da@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I think Herbert was leaning towards `-Weverything`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 18:22:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 18:22:35 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.0ef09b7965564cf00b06ee2a446bede0@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I've talked with some folks on the committee informally, and with Gershom while I'm visiting New York at the moment: At the very least, I definitely think the warning for redundant constraints shouldn't be in the default warning set. It goes off in situations where there is no good way to mask it at this time. Somewhat ironically the "3 release compatible" version of adding `redundant-constraints` would be to add it as an option now and consider turning it on in -Wall in 8.4 when such a `-Wno-redundant-constraints` option would be supported by 3 releases of the compiler. Possibly with Gershom's suggestion from the mailing list of making unrecognized `-Wfoo` options emit a single warning about an unrecognized option rather than have the compiler emit an error and die. This wouldn't preclude adding it to ` -Wlint` or `-Weverything` when the warning overhaul goes in in 8.2. Putting it in `-Wall` weakens the 3 release policy in a way that requires users to use cabal trickery to pass ghc options to avoid warnings in an uncomfortable way -- since old GHCs won't recognize a `-Wno-redundant- constraints` option, but if you feel it really belongs there I guess that is just what we'd have to do. In a perfect world this'd be relegated to a sort of `-Wlint` which checks style. So, this seems to suggest a few ways forward 1) Just remove it from the default constraint set. This is the minimum we should do. 2) Remove it from both the default constraint set and -Wall. Implement Gershom's suggestion that unrecognized -Wfoo options passed to the compiler simply cause it to warn about an unrecognized option. This would give us the option to add it to whatever `-Wlint` equivalent is added in 8.2 and an option to bring it into `-Wall` in 8.4 and weaken the 3 release policy accordingly, but now in a way that doesn't require the user to play with cabal flags. 1 is easy but damages the already weak 3 release policy almost to the point of irreparability: few people seem willing to use if clauses in cabal files, the reaction is much the same as to CPP hacks. 2 is a fair bit more work, but would serve to placate the folks for whom we put the 3 release policy in place in the first place. I'd prefer 2, but we could live with 1 if the amount of work involved was too prohibitive and GHC HQ felt strongly about the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 18:26:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 18:26:13 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.71d43b050f5f1a05ac14c56d55358716@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:23 simonmar]: > > I think maybe we're talking about different things, let me try to clarify. > > * If you install a Haskell package to be used with GHC, you still need the `-dev` version of any C library dependencies. That's independent of your proposal in comment:16, because we need the -dev libraries when building standalone executables. Is the C library going to be a static (archive) or da dynamic (shared object) library? If it is the latter then I think it would still work with comment:16 and if we pass a linker flag (something along the lines of copy all DT_NEEDED tags for C libraries from the dummy SO into the executable) the performance impact would be small. But in the completely static case you are right, the dev dependency is always required. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 19:09:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 19:09:50 -0000 Subject: [GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive In-Reply-To: <051.8288963528e24dfd4127278f265607de@haskell.org> References: <051.8288963528e24dfd4127278f265607de@haskell.org> Message-ID: <066.f21689b62fe155d676a8411ea020f35a@haskell.org> #11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------+--------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11367 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 19:44:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 19:44:16 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.524fb9187ba8977189e49ccc1971a7b6@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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 adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 19:49:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 19:49:48 -0000 Subject: [GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive In-Reply-To: <051.8288963528e24dfd4127278f265607de@haskell.org> References: <051.8288963528e24dfd4127278f265607de@haskell.org> Message-ID: <066.38c7a9edbfb9f5956815250d08024c50@haskell.org> #11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------+--------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11367 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Comment (by mpickering): This actually looks a bit more fiddly than I thought. After typechecking the pat syn is split into the builder and the matcher. Thus in the desugaring, the buider is just treated like any other function bind (line 128 in DsBinds) which is the cause of the bad error message. A way to fix this would be to add a new constructor to IdDetails called PatSynBuilder which carries the PatSyn which was used to build the relevant Id. FunBind could then be changed to check whether the Id comes from a pat syn and modify the error message as appropriate. Does anyone else see an easier way? I guess the error messages should refer to the right things so I'll have to make these changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:03:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:03:47 -0000 Subject: [GHC] #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 Message-ID: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple ImpredicativeTypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this issue when attempting to compile `conduit` with GHC 8.0.1-rc1 (specifically, the [https://github.com/snoyberg/conduit/blob/master/conduit/Data/Conduit/Internal/Pipe.hs Data.Conduit.Internal.Pipe] module). This (greatly simplified) code, which compiles without issue on GHC 7.10.3: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} module Data.Conduit.Internal.Pipe where data Pipe o r = HaveOutput (Pipe o r) o mapOutputMaybe :: (o1 -> Maybe o2) -> Pipe o1 r -> Pipe o2 r mapOutputMaybe f (HaveOutput p o) = maybe id (\o' p' -> HaveOutput p' o') (f o) (mapOutputMaybe f p) }}} emits a GHC panic with GHC 8.0.1-rc1: {{{ [1 of 1] Compiling Data.Conduit.Internal.Pipe ( Wat.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): matchExpectedFunTys <> a_a15Z[tau:5] -> b_a15Y[tau:5] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note that this code does not require `-XImpredicativeTypes`, and removing the pragma makes the code compile again. Marking as high since it's a regression, but not highest because `-XImpredicativeTypes` has long been broken (see also #11319). Still, this currently happens on code in the wild, and perhaps it would be worth turning this into a more sensible error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:16:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:16:08 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error Message-ID: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- Currently, it's a fatal error to pass GHC a warning flag it doesn't recognise: {{{ $ ghc-8.1.20160111 -Wfoobar -c foobar.hs ghc: unrecognised flag: -Wfoobar Usage: For basic information, try the `--help' option. }}} However, in order to gain more flexibility adding/removing warning flags without requiring users to carefully guard which flags a given GHC version supports, it was suggested to make GHC more tolerating in case of unrecognised warning flags (which may either have been removed, or not yet available in the current GHC version). Specifically, I propose the following: 1. Handle `-Wno-` or `-W` for an unknown `` as a warning rather than an error 2. This warning gets its own token `unrecognised-warning-flag` (turned on by default), so that it can be controlled via the general warning facilities as well: - `-Wno-unrecognised-warning-flag` turns off such warnings - `-Wunrecognised-warning-flag` turns on such warnings explicitly - `-Werror=unrecognised-warning-flag` (once we have #11219) emulates the old behaviour - various other combinations with warning-sets, `-Werror` specifications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:23:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:23:24 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.7e993c8eba664c89a548b1b837265306@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: #11369 => #11369, #11429 Comment: Replying to [comment:7 ekmett]: > I think Herbert was leaning towards `-Weverything`. Indeed, because we have a precedent in `clang` which uses `-Weverything` for that very purpose (since `-Wall` is traditionally doesn't comprise *all* warnings for gcc/clang, which is probably also the origin from where GHC copied this tradition...) Replying to [comment:8 ekmett]: > Possibly with Gershom's suggestion from the mailing list of making unrecognized `-Wfoo` options emit a single warning about an unrecognized option rather than have the compiler emit an error and die. Filed as #11429 -- if we agree this is a sensible thing to do, I think we should try to get this done in time for GHC 8.0 to extend the compat- window as far back as possible, i.e. starting at GHC 8.0 for a `-Wno- unrecognised-warning-flags` (module bikeshed) support -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:24:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:24:09 -0000 Subject: [GHC] #11422: outofmem RTS testcase fails on Windows In-Reply-To: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> References: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> Message-ID: <059.719b003a8f6cf815f46b547a7a283f89@haskell.org> #11422: outofmem RTS testcase fails on Windows ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: outpfmem Blocked By: | Blocking: Related Tickets: #11300 | Differential Rev(s): Phab:D1753 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"db371c10a2da722a18b0d5bc042eb2d02ba60e1b/ghc" db371c10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db371c10a2da722a18b0d5bc042eb2d02ba60e1b" T11300: Fix test on windows Summary: Fix exit code for Windows to match expected for out-of-memory test Test Plan: ./validate Reviewers: simonmar, austin, thomie, bgamari Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1753 GHC Trac Issues: #11422 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:26:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:26:57 -0000 Subject: [GHC] #11422: outofmem RTS testcase fails on Windows In-Reply-To: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> References: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> Message-ID: <059.464ce64dc08f1df2c4eedd3cb7a111e9@haskell.org> #11422: outofmem RTS testcase fails on Windows ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: outpfmem Blocked By: | Blocking: Related Tickets: #11300 | Differential Rev(s): Phab:D1753 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:27:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:27:56 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.c6a610f7440b413748d14077b50f63c3@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by hvr): PS: there some circular implementation details here I'm deliberately ignoring; I'm aware this may require some special handling for this new flag, rather than being handled uniformly like the other flags. I'm more inclined to have a uniform CLI appearance to the user than a uniform implementation... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:31:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:31:45 -0000 Subject: [GHC] #11430: ApiAnnotations: work SourceText in for all integer literals Message-ID: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> #11430: ApiAnnotations: work SourceText in for all integer literals -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Certain syntactic elements have integers in them, such as fixity specifications, SPECIALISE pragmas and so on. The lexer will accept mult-radix literals, with arbitrary leading zeros in these. Bring in a SourceText field to each affected AST element to capture the original literal text for use with API Annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:34:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:34:54 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.ef19e7051c7d6d67740710ed3e89e55e@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1773 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"49e414a736efe6a5aa221907d9eab9019978e225/ghc" 49e414a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49e414a736efe6a5aa221907d9eab9019978e225" Remove lookup of sections by name instead use the index numbers as offsets Summary: This patch comes from @awson {{{ Playing with `-fsplit-sections` on Windows I've found a pile of ancient (it was borrowed from Hugs interpreter code and I don't even know when was it created), absolutely redundant and plain wrong code in RTS linker. Technically it is a bug, but it doesn't break things when used with current Windows binutils with no special linker scripts involved. OTOH, it slows down runtime linker on Windows noticeably and thus can be considered as a performance bug. The nice side-effect for existing users is that GHCi now loads compiled object code much faster on Windows. }}} More specifically, sections were being looked up by name by doing a loop over all sections until the section with the given name is found. The new approach uses the section index and finds the section in O(1) time based on information gathered when we originally processed the section Test Plan: ./validate (was run on GHC x86) Reviewers: austin, awson, erikd, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: awson, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1773 GHC Trac Issues: #11388 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 20:38:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 20:38:13 -0000 Subject: [GHC] #11388: Bad Windows PE handling in GHC runtime linker In-Reply-To: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> References: <044.08bd75be7844a44b1c4d39b08e966ef3@haskell.org> Message-ID: <059.0951db7e19c7c0c2532247c8e9dbc22a@haskell.org> #11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1773 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 21:02:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 21:02:12 -0000 Subject: [GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling In-Reply-To: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> References: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> Message-ID: <061.a91636893e2837c7495808a7f30115e3@haskell.org> #11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: GHC API | Version: 7.10.3 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 DanielG): * cc: DanielG (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 21:06:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 21:06:34 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.9dce4cc1957645eabc36f43090f139b1@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 phadej): * Attachment "ticket11427.hs" added. Failing file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 21:09:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 21:09:57 -0000 Subject: [GHC] #11430: ApiAnnotations: work SourceText in for all integer literals In-Reply-To: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> References: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> Message-ID: <059.9c01192152e4394c13865df7ad88cdbe@haskell.org> #11430: ApiAnnotations: work SourceText in for all integer literals -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Affected hsSyn elements are {{{#!hs -- See note [Pragma source text] data Activation = NeverActive | AlwaysActive | ActiveBefore SourceText PhaseNum -- Active only *strictly before* this phase | ActiveAfter SourceText PhaseNum -- Active in this phase and later deriving( Eq, Data, Typeable ) -- Eq used in comparing rules in HsDecls }}} {{{#!hs data Fixity = Fixity SourceText Int FixityDirection -- Note [Pragma source text] deriving (Data, Typeable) }}} and {{{#!hs | HsTickPragma -- A pragma introduced tick SourceText -- Note [Pragma source text] in BasicTypes (StringLiteral,(Int,Int),(Int,Int)) -- external span for this tick ((SourceText,SourceText),(SourceText,SourceText)) -- Source text for the four integers used in the span. -- See note [Pragma source text] in BasicTypes (LHsExpr id) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 21:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 21:35:34 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls Message-ID: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Consider the following use of `error`. {{{ ghci> :t error error :: forall (v :: GHC.Types.Levity) (a :: TYPE v). (?callStack::GHC.Stack.Types.CallStack) => [Char] -> a ghci> :t error "bad" :: (forall a. a -> a) -> a error "bad" :: (forall a. a -> a) -> a :: (?callStack::GHC.Stack.Types.CallStack) => (forall a1. a1 -> a1) -> a }}} GHC is instantiating the type variable `a` in the output with `(forall a. a -> a) -> a`, which requires impredicative polymorphism. So this example should actually be rejected by the type checker. Note that GHC also does this with open-kinded type variables, so the behavior with `error` and `undefined` has been around for a while. There are tests that depend on it, and a Note that describes the decision to accept these programs. Still, Simon PJ says perhaps we should really just reject these programs. So here's a ticket to discuss the matter. For more information, see the discussion starting at https://phabricator.haskell.org/D1739#51408. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 21:42:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 21:42:31 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.a6827566466947a6a2491b3d3b11869e@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > 2) Remove it from both the default constraint set and -Wall. Doesn't that mean that 8.2 will be in ''precisely'' the same situation as 8.0, and we'll just have the identical conversation then? What is `-Wlint`? Is it the same as `-Weverything`? What does it mean? Perhaps this: * Default warnings are what you get by default. Is there a flag `-Wdefault`? * `-Wall` means a larger set. * `-Weverything` means the entire set. Plus there is some protocol that a new warning always starts in `-Weverything`; may move in the next release to `-Wall`; and may move in the release after that to the default set. Both moves are a judgement call. Maybe I have this wrong. It would be super-helpful if someone could lay our the entire proposal. It doesn't look hard to implement in 8.0 if I have it roughly right, and someone is willing to step up to do it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 22:11:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 22:11:00 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.24bc3cc9fdd6ff24511abee73d9e4f0f@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): > Doesn't that mean that 8.2 will be in precisely the same situation as 8.0, and we'll just have the identical conversation then? The main difference is that in 8.2 we'd have at least 2 releases with #11429 resolved, so if users used `-Wno-whatever` and the compiler didn't understand it, it'd not be a hard error. That makes increasing the length of the options list that the 3 release policy applies to a fair bit more palatable. By 8.4 users wouldn't even have to use cabal flags, so in many ways this is the same conversation, but it gets easier to resolve the further out we push. > Plus there is some protocol that a new warning always starts in -Weverything; may move in the next release to `-Wall`; and may move in the release after that to the default set. Both moves are a judgement call. That sounds like a good rubric to me. All of the warnings we'd need for the items on the current roadmap (https://prime.haskell.org/wiki/Libraries/Proposals) seem to fit these guidelines. As for `-Wlint` it was just a suggestion as to what one of the extended warning sets might be, if it existed at all, it'd be included in `-Weverything`. Herbert has given a lot more thought to what groupings of flags make sense than I have, and I'm happy to defer to him there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 22:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 22:21:01 -0000 Subject: [GHC] #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 In-Reply-To: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> References: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> Message-ID: <065.22ad7005012b0d514b4713c24df51177@haskell.org> #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | ImpredicativeTypes, | TypeApplications 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): * keywords: ImpredicativeTypes => ImpredicativeTypes, TypeApplications * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 22:42:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 22:42:54 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.ffa651227f65b491cde1d228df10cd30@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): I think Ed's comments on the two proposed plans of action are exactly right. Note that two things by the way are intersecting here: 1) GHC adding new warnings in general, which is largely unrelated to the 3-release policy but should be generally managed with some degree of rollout and 2) The presence of warnings at all such as redundant superclasses, which by their very nature warn against code that is necessary and desirable in migration paths. So lots of the details here don't apply to most warnings added -- they apply to this particular one, and adding features so that it and similar warnings can more easily not stand in the way of library evolution, in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 22:59:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 22:59:13 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.beea69c0ed9442742b9094c1aa8a0f80@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It would be super-helpful if someone could lay our the entire proposal. Since you are clear, might one of you do this? On a wiki page where we can refine the text to clear up ambiguities. I'm not capable of composing all these comments in my head to get the end result. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 14 23:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jan 2016 23:26:15 -0000 Subject: [GHC] #11415: pandoc-types fails to build on 4 GB machine In-Reply-To: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> References: <049.3f4a5adbe3ed958aec19c26d7f43bc21@haskell.org> Message-ID: <064.2de77d59d58b7ab599d8ae27cc073837@haskell.org> #11415: pandoc-types fails to build on 4 GB machine -------------------------------------+------------------------------------- Reporter: pavolzetor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Generics 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 pavolzetor): I think it is related to this bug [https://github.com/bos/aeson/issues/296]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 00:03:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 00:03:25 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.1288e6406fd4bbc71aa68fb070cb038f@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Well, it's literally a two line change. I'm willing to flip the switch. Anyone else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 03:06:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 03:06:42 -0000 Subject: [GHC] #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 In-Reply-To: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> References: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> Message-ID: <065.3d82e1b21c95b20e43487d35f01234cc@haskell.org> #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | ImpredicativeTypes, | TypeApplications 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): Hopefully my work (Phab:D1777 is an unfinished checkpoint) toward #11397 will nab this as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 03:10:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 03:10:58 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.b132fd130199a7fe8aa3d6c260f7c56e@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): I think the current behavior is fine, if somewhat unexpected. (We should document it if we haven't.) There is no such thing as a levity-polymorphic value. (If there were, how much space would it take up?) Thus, any levity-polymorphic expression must be bottom. So I don't see how a tiny bit of impredicativity just for bottoms can cause trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 03:24:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 03:24:15 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.8602d1e926c3226c638efaea1a3e4e61@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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'm lost here. Why are we generating a wanted constraint for an instance constraint? Shouldn't that be given? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 04:16:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 04:16:08 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.ff8e83b06de6db497d72958a25b9e64c@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek 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 | -------------------------------------+------------------------------------- Comment (by goldfire): Despite the work you've done on this, I am becoming less convinced that we should fix #6024. Reading the code, I realized that this extension would allow users to define data constructors that live only in types, but there's no way to make one that lives only in terms! That seems oddly asymmetrical. It might be worth a wider discussion about the merits of kind-only datatypes in GHC 8.x. Of course, none of this applies to open kinds, which are indeed still very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 04:22:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 04:22:04 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.f0c9e6f972249ec23752e3dc5e3fa3de@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I want to note that the Haskell Report says that `3` desugars to `fromInteger THREE`. Perhaps we can indeed hack around this by using `integerLit`. But then turning on `RebindableSyntax` would necessitate using `fromInteger`, which (due to its membership in the `Num` class), must have type `forall a. Num a => Integer -> a`, where the `forall a` just comes too early. This would mean that `3 @Int` would work with `-XNoRebindableSyntax` but then fail with `-XRebindableSyntax` (when importing `Prelude`). It would all be rather unexpected. Worse than the status quo? I don't know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 05:38:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 05:38:08 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.2400c9ca2f206ee623fc305791bcbd74@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1776 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"91f1c600614e8c456a62bd95611400b442113cdf/ghc" 91f1c60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91f1c600614e8c456a62bd95611400b442113cdf" Fix #11015 with a nice note. Signed-off-by: Edward Z. Yang Test Plan: doc only Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1776 GHC Trac Issues: #11015 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 06:18:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 06:18:02 -0000 Subject: [GHC] #11380: `cabal repl` exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.882cbde057a8cbab51a457575ea9debc@haskell.org> #11380: `cabal repl` exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I have a project that depends on happy/alex to generate parsers. > (https://github.com/TOSPIO/pyn) > > Running `cabal repl` on my laptop with 16GiB memory ended up eating up > all memory and eventually resulted in kernel panic. > > `cabal build` works fine. Problem arises when compiling the giant happy- > generated dist/build/Language/Python/Parser/Parse.hs file > > also `cabal repl --ghc-options=-fobject-code` works fine. New description: I have a project that depends on happy/alex to generate parsers. (https://github.com/TOSPIO/pyn) Running `cabal repl` on my laptop with 16GiB memory ended up eating up all memory and eventually resulted in kernel panic. Problem arises when compiling the giant happy-generated dist/build/Language/Python/Parser/Parse.hs file. The memory usage is flat (~1.5G) within the first 2 mins, and the soars up to over 10GB within seconds. `cabal build` and `cabal repl --ghc-options=-fobject-code` works fine. -- Comment (by kennethb): I noticed that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 07:06:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 07:06:33 -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.63665721d971a9773aa31ae47dc86356@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 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-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 08:43:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 08:43:44 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.b7b4a0b230e9876cbac8a4e5a74dfa25@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 phadej): goldfire: isn't situation a bit like {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} class MyEq a where myeq :: a -> a -> Bool class MyEq a => MyOrd a where mycomp :: a -> a -> Ordering class MyClass a where mydef :: a -> Bool instance MyOrd a => MyClass a where mydef x = myeq x x }}} This small example works though. i.e. by requiring ` All SListI xss =>` we also should get `SList xss` to use `sList`. Or I'm reading generics-sop code very wrong myself (it's not mine)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 09:41:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 09:41:46 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.9524be9c87de9bcbbb23453db58155d3@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 phadej): goldfire: I can break previous example by adding `MyEq a` constraint to `MyClass`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} class MyEq a where myeq :: a -> a -> Bool class MyEq a => MyOrd a where mycomp :: a -> a -> Ordering class MyEq a => MyClass a where mydef :: a -> Bool instance MyOrd a => MyClass a where mydef x = myeq x x }}} AFAICS, `MyOrd a` in instance declration should provide `MyEq a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 10:03:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 10:03:10 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.f0a6e3ffcb793fd155999c1ae4374bfc@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 don't see how a tiny bit of impredicativity just for bottoms can cause trouble. Impredicativity never causes trouble for the dynamic semantics; after all Core is impredicative. In contrast levity-polymorphism does. Impredicativity does cause trouble for type inference -- see zillions of papers on the subject. In contrast levity-polymorphism does not. (Except in enforcing the restrictions that levity polyormophism must follow to avoid screwing up the dynamic semantics.) There is no reason (that I can see) that the restrictions for levity polymorophism should be sufficient to avoid all type- inference/impredicativity difficulties. Maybe so, but it would be a coincidence. There's an engineering issue too. Richard is about to eliminate `RetTv`. But `RetTv` is essential to the implementation that accepts the above program. Are we going to leave `RetTv` for this sole (ill-defined) purpose? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 10:05:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 10:05:50 -0000 Subject: [GHC] #11430: ApiAnnotations: work SourceText in for all integer literals In-Reply-To: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> References: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> Message-ID: <059.f6dbb565feecb5e21767ffb79a244b2f@haskell.org> #11430: ApiAnnotations: work SourceText in for all integer literals -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 10:12:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 10:12:19 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.7bb484389d6e8e20ee2d8a3aa653d7d3@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): This is very delicate. And regrettably un-documented. It's explained in great detail in `Note [Recursive superclasses]` in `TcInstDcls`. I append the text below. In this case GHC is being a little over-conservative, but I don't know how to do it better. You can work around it in your example in comment:3 by adding `MyEq a` to the offending instance declaration: {{{ instance (MyEq a, MyOrd a) => MyClass a where mydef x = myeq x x }}} Simon {{{ Note [Recursive superclasses] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See Trac #3731, #4809, #5751, #5913, #6117, #6161, which all describe somewhat more complicated situations, but ones encountered in practice. See also tests tcrun020, tcrun021, tcrun033, and Trac #11427 ----- THE PROBLEM -------- The problem is that it is all too easy to create a class whose superclass is bottom when it should not be. Consider the following (extreme) situation: class C a => D a where ... instance D [a] => D [a] where ... (dfunD) instance C [a] => C [a] where ... (dfunC) Although this looks wrong (assume D [a] to prove D [a]), it is only a more extreme case of what happens with recursive dictionaries, and it can, just about, make sense because the methods do some work before recursing. To implement the dfunD we must generate code for the superclass C [a], which we had better not get by superclass selection from the supplied argument: dfunD :: forall a. D [a] -> D [a] dfunD = \d::D [a] -> MkD (scsel d) .. Otherwise if we later encounter a situation where we have a [Wanted] dw::D [a] we might solve it thus: dw := dfunD dw Which is all fine except that now ** the superclass C is bottom **! The instance we want is: dfunD :: forall a. D [a] -> D [a] dfunD = \d::D [a] -> MkD (dfunC (scsel d)) ... ----- THE SOLUTION -------- The basic solution is simple: be very careful about using superclass selection to generate a superclass witness in a dictionary function definition. More precisely: Superclass Invariant: in every class dictionary, every superclass dictionary field is non-bottom To achieve the Superclass Invariant, in a dfun definition we can generate a guaranteed-non-bottom superclass witness from: (sc1) one of the dictionary arguments itself (all non-bottom) (sc2) an immediate superclass of a smaller dictionary (sc3) a call of a dfun (always returns a dictionary constructor) The tricky case is (sc2). We proceed by induction on the size of the (type of) the dictionary, defined by TcValidity.sizeTypes. Let's suppose we are building a dictionary of size 3, and suppose the Superclass Invariant holds of smaller dictionaries. Then if we have a smaller dictionary, its immediate superclasses will be non-bottom by induction. What does "we have a smaller dictionary" mean? It might be one of the arguments of the instance, or one of its superclasses. Here is an example, taken from CmmExpr: class Ord r => UserOfRegs r a where ... (i1) instance UserOfRegs r a => UserOfRegs r (Maybe a) where (i2) instance (Ord r, UserOfRegs r CmmReg) => UserOfRegs r CmmExpr where For (i1) we can get the (Ord r) superclass by selection from (UserOfRegs r a), since it is smaller than the thing we are building (UserOfRegs r (Maybe a). But for (i2) that isn't the case, so we must add an explicit, and perhaps surprising, (Ord r) argument to the instance declaration. Here's another example from Trac #6161: class Super a => Duper a where ... class Duper (Fam a) => Foo a where ... (i3) instance Foo a => Duper (Fam a) where ... (i4) instance Foo Float where ... It would be horribly wrong to define dfDuperFam :: Foo a -> Duper (Fam a) -- from (i3) dfDuperFam d = MkDuper (sc_sel1 (sc_sel2 d)) ... dfFooFloat :: Foo Float -- from (i4) dfFooFloat = MkFoo (dfDuperFam dfFooFloat) ... Now the Super superclass of Duper is definitely bottom! This won't happen because when processing (i3) we can use the superclasses of (Foo a), which is smaller, namely Duper (Fam a). But that is *not* smaller than the target so we can't take *its* superclasses. As a result the program is rightly rejected, unless you add (Super (Fam a)) to the context of (i3). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 10:17:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 10:17:20 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.a6cbdf05493db6d965fdf41663b64f43@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think it'd be too bad if GHC's implementation desugared `3` to `integerLit THREE` always. For Haskell 98 or 2010, the behaviour would be indistinguishable from the report. But it'd work with `TypeApplications` too which is a real advantage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 11:07:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 11:07:25 -0000 Subject: [GHC] #11432: Cannot export operator newtype Message-ID: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeOperators #-} module Main (main, (-.->)(..)) where main :: IO () main = return () newtype (f -.-> g) a = Fn { apFn :: f a -> g a } }}} Fails to compile with {{{ [1 of 1] Compiling Main ( fn.hs, interpreted ) fn.hs:2:20: error: Not in scope: ?-.->? fn.hs:2:20: error: The export item ?(-.->)(..)? attempts to export constructors or class methods that are not visible here }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 11:27:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 11:27:10 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. Message-ID: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- When building the Debian package, the build fails with {{{ writing output... [100%] win32-dlls generating indices... genindex writing additional pages... search copying images... [100%] images/prof_scc.svg copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 5 warnings. /usr/bin/sphinx-build -b man -d docs/users_guide/.doctrees-man docs/users_guide docs/users_guide Error: source directory and destination directory are same. docs/users_guide/ghc.mk:30: recipe for target 'docs/users_guide/ghc.1' failed make[3]: *** [docs/users_guide/ghc.1] Error 1 Makefile:122: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/<>' }}} Full build log attached. Any idea what might be causing this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 11:30:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 11:30:04 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.149c37f65758eb450549cae2a50f06c5@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc1 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 nomeata): * Attachment "ghc_8.0.0.20160111-1_amd64.build.xz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 11:35:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 11:35:07 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.e7a1201187b56f6bb8a498859003ace4@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > Is the C library going to be a static (archive) or da dynamic (shared object) library? Usually both, so that you can use `-optl-static` if you want. The `-dev` package of a C library normally includes both the unversioned `.so` and the `.a`. Remember that GHC links static Haskell packages but dynamic C libraries by default. > If it is the latter then I think it would still work with comment:16 and if we pass a linker flag (something along the lines of copy all DT_NEEDED tags for C libraries from the dummy SO into the executable) the performance impact would be small. Did you know the code in `Linker.lhs` is only used for GHCi and not linking of standalone executables? I have a suspicion that there's some confusion here. There is no "dummy SO" when linking a standalone executable. Since you have a design in mind, maybe it would be good to flesh it out in a wiki page so we can discuss with more precision? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 11:38:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 11:38:22 -0000 Subject: [GHC] #11427: TypeSynonyms not deduced In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.48cb9a592c56e4435b3514d19f20fbe2@haskell.org> #11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 phadej): Ok, so this is special case which has a elegent-enough workaround. I guess the error message could be better: {{{ ? Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at foo.hs:39:3-40 Note: superclasses of (All SListI xss) aren't considered, because it's no smaller then the instance head. }}} or some variation of that. ''arising from the superclasses of an instance'' is a bit misleading in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 11:53:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 11:53:46 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.ce5c1b08193e52c34608f990f4dc3e76@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 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 niteria): * priority: normal => high Comment: This is a blocker for #4012. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:00:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:00:32 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.609759e0652ce62d0f44eff406e523ec@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc1 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): Indeed, I'm just confused as to why this hasn't been happening locally. In my experience `sphinx-build` doesn't mind the source and destination directories being coincident. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:05:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:05:33 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.8eb709968d71626cc8669a9c3e63879c@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1782 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:08:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:08:21 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.b59c8cfdcbce666d1af052c5aad475e6@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This is `python-sphinx` version 1.3.3 here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:08:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:08:35 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.65dbbd71e48e46a292ae5ab9066db5db@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1776 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Also merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:46:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:46:20 -0000 Subject: [GHC] #11427: superclasses aren't considered because context is no smaller than the instance head (was: TypeSynonyms not deduced) In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.2855f2d7d4d26092a7ac48692cea08d3@haskell.org> #11427: superclasses aren't considered because context is no smaller than the instance head -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 Fri Jan 15 12:53:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:53:53 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.d943aba40fb70ae2c1e3bad50b4fe21d@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:54:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:54:46 -0000 Subject: [GHC] #11427: superclasses aren't considered because context is no smaller than the instance head In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.092688e192297a4c552e70e4ed3c542f@haskell.org> #11427: superclasses aren't considered because context is no smaller than the instance head -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 12:58:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 12:58:05 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.7e6b64366229df16f5282f893ac2cabd@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): This happens with 8.0.1-rc1 still. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 13:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 13:48:04 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.d2b9e45411c2e71991f2a25c78d7c33e@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by bgamari): hvr, what is the status of this? Phab:D339 has been merged and we now always use `integer-gmp2` but we appear to build against `gmp-6.0.0-3` on Windows. Perhaps we should bump this so we can close this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 13:53:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 13:53:19 -0000 Subject: [GHC] #11420: Incorrect links In-Reply-To: <043.892271951d8342b4b169aedd748e7403@haskell.org> References: <043.892271951d8342b4b169aedd748e7403@haskell.org> Message-ID: <058.ca035c629bd9538a55cf207d7dbfed50@haskell.org> #11420: Incorrect links -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This was due to an issue with the script responsible for generating this page. Both the script and the page have been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 13:53:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 13:53:28 -0000 Subject: [GHC] #11420: Incorrect links In-Reply-To: <043.892271951d8342b4b169aedd748e7403@haskell.org> References: <043.892271951d8342b4b169aedd748e7403@haskell.org> Message-ID: <058.b7e38174270875af36ee04b0ef2b1974@haskell.org> #11420: Incorrect links -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for your report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:21:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:21:17 -0000 Subject: [GHC] #11434: Drop bzip2 in favor of xz Message-ID: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> #11434: Drop bzip2 in favor of xz -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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 January 2016 it was proposed that we stop providing bzip2 tarballs, instead only offering xz-compressed tarballs. This ticket is to track this process. Ben Gamari brought this proposal to the [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026123.html|mailing lists] where there was no objection. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:22:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:22:38 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.d714c2bb298a5380bade59d1ea9c9ebe@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 * milestone: => 8.0.1 Comment: This is a regression relative to 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:32:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:32:27 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.d1728425a0c5bb4b561385926b3742f1@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Replying to [comment:2 simonpj]: > There's an engineering issue too. Richard is about to eliminate `RetTv`. But `RetTv` is essential to the implementation that accepts the above program. Are we going to leave `RetTv` for this sole (ill-defined) purpose? Yes, I recognize that as an unfortunate consequence of this suggestion. But it wouldn't be `ReturnTv` -- it would go back to the old `PolyTv`, just a tyvar that's allowed to unify with a polytype. Agreed that, if this works, it's a coincidence. That does seem to suggest that it doesn't work. My hope that it would work is because levity polymorphism is vanishingly rare. In any case, I don't feel strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:32:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:32:44 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.6165a7abc1556fd959c69ba67e4231d2@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | 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 simonpj): * keywords: => TypeApplications Comment: Tagging this with `TypeApplications`. Not strictly correct, but in the same general territory and I don't want to lose track of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:33:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:33:15 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.e8e3cffd91cb3478ecbbe58a71d1f300@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What about with `RebindableSyntax`? Changing that behavior would likely break quite a bit of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:35:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:35:05 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.90868a2d4ddb07a724986e603cfb0025@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yurgh. Maybe with `RebindableSyntax` we stick with `fromInteger`. Or maybe it's a breaking change. Maybe we should do nothing until someone really says it's important to them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:41:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:41:57 -0000 Subject: [GHC] #11423: GHC 8.0-rc1's linker does not work in OSX In-Reply-To: <046.4d046600b2eefbe174b22f5b5b3bb063@haskell.org> References: <046.4d046600b2eefbe174b22f5b5b3bb063@haskell.org> Message-ID: <061.baa503c5577f486e8d1cfbc4ef351286@haskell.org> #11423: GHC 8.0-rc1's linker does not work in OSX ---------------------------------+---------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I have pushed out a [http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64 -apple-darwin.tar.xz|new] binary distribution with a correctly-linked `libgmp`. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:42:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:42:13 -0000 Subject: [GHC] #11435: Evidence from TC Plugin triggers core-lint warning Message-ID: <047.84e4b39cae85829cc41b2b95d0dbdb9b@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: core-lint | Operating System: Linux warning evidence type-checker | plugin | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached plugin and program produce a core-lint warning that refers to evidence the plugin did not produce. == High-Level description of what the plugin does and what happens 'flatFilter' produces the following ambiguous wanted constraints: {{{ Polymonad (Reader '["thres" :-> Int]) n (Reader '["thres" :-> Int]) (CNonCanonical) Polymonad (Reader '["thres" :-> Int]) m n (CNonCanonical) Polymonad Identity Identity m }}} To solve these the plugin does the following: 1. It produces two type equality constraints: {{{ n ~ Identity (CNonCanonical) m ~ Reader '["thres" :-> Int] (CNonCanonical) }}} 2. As a result of these equality constraints the GHC constraint solver creates the following wanted constraint: {{{ Polymonad (Reader '["thres" :-> Int]) Identity (Reader '["thres" :-> Int]) (CNonCanonical) }}} GHCs constraint solver can not pick an instance because several instances overlap: {{{ P.Monad f => Polymonad f Identity f ( Effect m, E.Inv m f (Unit m), f ~ Plus m f (Unit m)) => Polymonad (m (f :: [*])) Identity (m (f :: [*])) }}} By trying to produce evidence for either of these instances the plugin determines that only the second instance is actually applicable and therefore selects it and produces evidence. With this the constraints are solved and the type checking/constraint solving stage is done. During core linting we get the following error: {{{ *** Core Lint errors : in result of Simplifier *** : Warning: [RHS of ds_a66V :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) }}} As can be seen in the plugin [Check for 'Nth' constructor] the evidence produced by the plugin does not contain the 'Nth' constructor for coercions/evidence anywhere. Thus, the produced evidence seems to trigger GHC to produce these 'bad' coercions/evidence somewhere. == Building the Example The example should be self-contained and reproduces the error whenever you try to build it. You can find it here or in the attachment: https://github.com/jbracker/polymonad-plugin/tree/master/examples/core- error You just have to download the three files and run "cabal install" to reproduce the error. There is a high-level explanation of what is going on above and in the 'Main.hs' from line 83. The plugin 'MinimalPlugin.hs' is still around 600 lines long, but I have added a lot of comments to make it comprehensible. I suppose the most interesting part is the production of evidence in 'MinimalPlugin.hs' from line 198. I have added checks to see if the evidence I produce contains the 'Nth' constructors the core-lint warning refers to in line 130 and 556 of the plugin, but the evidence produced does not contain them. So somehow the evidence triggers GHC to produce evidence that the core-linter warns about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 14:45:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 14:45:39 -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.514b7a5ef22b32e787aee7e693b590a2@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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 jbracker): * Attachment "core-error.zip" added. File of the core warning example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:27:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:27:36 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.2e47688ab8398758a72efef05c03bfec@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So I have a very rough cut of Richard's proposal. The primary wrinkle that I ran into here is that you are forced to produce the `GHC.Prim` representations as `CoreExpr`s in order to wire them in (as wired-in identifiers are just identifiers without a definition but instead a compulsory unfolding, which is Core). This is a bit unfortunate as in the usual case we produce representations as standard `HsExpr`s, meaning we must duplicate the code for producing type representations. There are three options I can see here, 1. Accept the code duplication and move on with life 2. Use compulsory unfoldings for all type representations, allowing us to drop the current `HsExpr` logic in `TcTypeable` 3. Instead make the `GHC.Prim` representations merely known-key and inject the bindings into some other module (like `GHC.Types`, since `GHC.Prim` doesn't have associated object code). This means we'd keep some of the special-case that we currently have, but on the other hand we could drop the hand-written type representations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:28:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:28:03 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.1ad5fb6c4e8581b14de6944a8c471846@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:25 simonmar]: > > Is the C library going to be a static (archive) or a dynamic (shared object) library? > > Usually both, so that you can use `-optl-static` if you want. The `-dev` package of a C library normally includes both the unversioned `.so` and the `.a`. > > Remember that GHC links static Haskell packages but dynamic C libraries by default. Static Haskell with dynamic C is the issue that I want to address in comment:16 > [...] > Did you know the code in `Linker.lhs` is only used for GHCi and not linking of standalone executables? I have a suspicion that there's some confusion here. There is no "dummy SO" when linking a standalone executable. Sorry, this is indeed confusing. This dummy SO is not the same as the dummy SO in #10458. Let me call the #11458 dummy SO "GHCi dummy SO" and the one in comment:16 "package dummy SO". The package dummy SO belongs to a Haskell package and is installed next to the static (`libHS*.a`) and the dynamic (`libHS*.so`) Haskell library. Then the package dummy SO would be used in the static Haskell dynamic C case in GHCi only. We could do this to help user's that are in the situation described in this ticket. On the other hand we could include the essence of your comment:19 "GHCi works like ld" in the user's guide (Section 2.6.2?). Perhaps we can discuss this in [wiki:LinkingHaskell] When linking a static executable a static executable then all C dev dependencies are required. That is no different from linking a C executable. > > Since you have a design in mind, maybe it would be good to flesh it out in a wiki page so we can discuss with more precision? I created [wiki:LinkingHaskell] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:31:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:31:05 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.92310bf604b131f4708de046ec67aba1@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Geraldus Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: completions | complete command operator Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9996 | Differential Rev(s): Phab:D1058 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Geraldus): * differential: => Phab:D1058 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:31:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:31:19 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.21be7d11d3014ad5b7b3b9d02d6ef6d0@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"c6a3e2277aef2d3b8a472cc82542c9b22cea86bf/ghc" c6a3e227/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6a3e2277aef2d3b8a472cc82542c9b22cea86bf" Link command line libs to temp so Symbols in libraries specified on the GHCis command line are not available to compiled modules because shared libraries are loaded with local scope. So we link all libraries specified on the command line into each temporary shared library. Test Plan: validate Reviewers: simonmar, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1631 GHC Trac Issues: #10458 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:31:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:31:19 -0000 Subject: [GHC] #11434: Drop bzip2 in favor of xz In-Reply-To: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> References: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> Message-ID: <061.b705f26cf1b6af5cdf9c63197edaa6ff@haskell.org> #11434: Drop bzip2 in favor of xz -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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 Ben Gamari ): In [changeset:"e7eec3a1c6ec46dc5b0d9d84c8a894b6f7e27f63/ghc" e7eec3a1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7eec3a1c6ec46dc5b0d9d84c8a894b6f7e27f63" Use XZ compression by default Resolves #11434. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:32:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:32:28 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.e2582d349fe54e0fe4e34c662831eb10@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: mpickering Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 mpickering): * owner: => mpickering Comment: This is a problem in the parser. Workaround, use the `type` keyword. {{{ {-# LANGUAGE TypeOperators #-} module T11432 (type (-.->)(..)) where newtype (f -.-> g) a = Fn { apFn :: f a -> g a } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 15:38:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 15:38:04 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.c47a1a6ba404b7fd6f9ded7ca5ee10f4@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `master` and `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 16:39:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 16:39:38 -0000 Subject: [GHC] #11348: Local open type families instances ignored during type checking In-Reply-To: <048.419b44d406ca8091f032a727fdd29058@haskell.org> References: <048.419b44d406ca8091f032a727fdd29058@haskell.org> Message-ID: <063.5ca3a8bda24811f3db4c56e6cc19ab16@haskell.org> #11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): Phab:D1762 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:15:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:15:29 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.c4d9e80bfe04054a70a34a616d239765@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7cf16aaf6d08a6be7f4c4a20b8684d61e1ee3163/ghc" 7cf16aa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7cf16aaf6d08a6be7f4c4a20b8684d61e1ee3163" Don't output manpage in same directory as source Test Plan: Validate Reviewers: austin, thomie, nomeata Differential Revision: https://phabricator.haskell.org/D1782 GHC Trac Issues: #11433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:15:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:15:29 -0000 Subject: [GHC] #11345: Template Haskell's handling of infix GADT constructors is broken In-Reply-To: <050.9f334c84b36879f857088cd172154790@haskell.org> References: <050.9f334c84b36879f857088cd172154790@haskell.org> Message-ID: <065.c6c27f9206b40d8ca2b79b1dbff706a2@haskell.org> #11345: Template Haskell's handling of infix GADT constructors is broken -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 8.0.1-rc1 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): Phab:D1744, Wiki Page: | Phab:D1766 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"756b22832e2ba5713e5bb8201eedf1d04db729a8/ghc" 756b2283/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="756b22832e2ba5713e5bb8201eedf1d04db729a8" Refactor lookupFixityRn-related code following D1744 Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1766 GHC Trac Issues: #11345 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:15:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:15:29 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.bb970e730e40b573643517cb8da74d38@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"443bf04485f997be2e3a744102605645c54e9d61/ghc" 443bf04/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="443bf04485f997be2e3a744102605645c54e9d61" Allow pattern synonyms which have several clauses. But still disallow empty pattern synonym builder declarations. Handling this incorrectly was the cause of #11367. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1779 GHC Trac Issues: #11367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:15:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:15:29 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced In-Reply-To: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> References: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> Message-ID: <065.8447d35f1afb9273e73444e3b83291a5@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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): Phab:D1772 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"165ae440b6bbf577eabf0b6d422ed6ea3bf949b4/ghc" 165ae440/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="165ae440b6bbf577eabf0b6d422ed6ea3bf949b4" Expand type/kind synonyms in TyVars before deriving-related typechecking Before, it was possible to have a datatypes such as ``` type ConstantT a b = a newtype T (f :: * -> *) (a :: ConstantT * f) = T (f a) deriving Functor data family TFam (f :: * -> *) (a :: *) newtype instance TFam f (ConstantT a f) = TFam (f a) deriving Functor ``` fail to eta-reduce because either (1) a TyVar had a kind synonym that mentioned another TyVar, or (2) an instantiated type was itself a type synonym that mentioned another TyVar. A little bit of tweaking to `expandTypeSynonyms` and applying it before the eta-reduction check in the `deriving` machinery is sufficient to fix this. Fixes #11416. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1772 GHC Trac Issues: #11416 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:20:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:20:45 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.9ed4171c1f3b245627814b41d3498526@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 mpickering): * owner: mpickering => Comment: I can't work out how to fix this. The problem is that (-.->) is put into the variable namespace rather than the type constructor namespace. However, I change the parsing rules to how they were in ghc-7.10.3 and it still doesn't accept it. Maybe that commit is responsible but I'm not sure anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:32:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:32:55 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.d990e6a8c4c2ac83da79d167583b83e2@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 diatchki): Perhaps there is a different way to do the reduction that avoids this problem. My mental model of type functions is that: 1. they only ever ***name*** types, they never introduce ***new*** types, which arise from `data`, `newtype` and primitives. 2. they may be partial, so sometimes they don't name any type at all. I find it easiest to think about all this in terms of GHC's internal representation of the constraints, so your example would look something like this: {{{ (Same a [a] ~ Char, Loop Int ~ a) }}} Now, I think reducing `Same a [a] ~ Char` to `Char ~ Char`, and then just eliminating it as a trivial equality is perfectly valid. However, eliminating the `Loop Int ~ a` constraint is what's questionable here, even if `a` is not used anywhere. This constraint essentially says that `Loop Int` must be well-defined, in other words, it better refer to an actual ground type that exists. One (fairly simple?) way for GHC to check the validity of such constraints would be to simply evaluate them until it does find the ground type in question. In your example, this would result in GHC non-terminating during type checking, which is perfectly reasonable, especially since you need `UndecidableInstaces` to write such recursive types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:39:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:39:12 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.f415479ef9098165f2eba4f7cb4cf3a7@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:46:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:46:32 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.6697cc0078e8386453b0eab8df87e8ac@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie): * cc: skvadrik (added) Comment: skvadrik: maybe you can have a look, as the author of the commit mentioned in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:53:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:53:24 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.c2746dc21838550595e403d709f90af1@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): There's not going to be an easy solution to this. The problem is that we only know that `(-.->)` is a type when we see the open parenthesis after it. But the parser has only one-token lookahead. I would actually say that the current behavior -- requiring `type` -- is correct. We then have a rule that's simple for both parsers and people: any symbol not beginning with a `:` is assumed to be a variable, not a type. Note that we don't need to worry about standards-compliance here, as `TypeOperators` is not standardized. If it doesn't already, `TypeOperators` should imply `ExplicitNamespaces`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:55:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:55:27 -0000 Subject: [GHC] #11436: ValueError: invalid literal for int() with base 10: '#11238' Message-ID: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> #11436: ValueError: invalid literal for int() with base 10: '#11238' -------------------------------------+------------------------------------- Reporter: trommler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ==== How to Reproduce ==== While doing a POST operation on `/ticket/9498`, Trac issued an internal error. I changed the ticket number in field BlockedBy and trac does not like the hash mark. The ticket is updated nevertheless and the hash marks on the ticket numbers in the Blocking field are gone too. Links to the tickets are no longer present. Request parameters: {{{ {u'__FORM_TOKEN': u'2c077745a0bf5115b3e543fe', u'action': u'leave', u'comment': u'', u'field_architecture': u'Unknown/Multiple', u'field_blockedby': u'#11238', u'field_blocking': u'#9237', u'field_cc': u'trommler, simonmar', u'field_component': u'Compiler (Linking)', u'field_description': u"Greetings,\r\n\r\nGHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3).\r\nThis is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones.\r\nThis means FFI libraries depend on the -dev packages, even though they don't really need them.\r\nIt would be nice if GHC would try to load the versioned libraries as well.\r\n\r\nRegards\r\nSven", u'field_differential': u'', u'field_failure': u'Other', u'field_keywords': u'Debian', u'field_milestone': u'', u'field_os': u'Linux', u'field_priority': u'normal', u'field_related': u'', u'field_summary': u'GHC links against unversioned .so files', u'field_testcase': u'', u'field_type': u'feature request', u'field_version': u'7.6.3', u'field_wikipage': u'', 'id': u'9498', u'preview': u'Preview', u'replyto': u'', u'sfp_email': u'', u'sfph_mail': u'', u'start_time': u'1452879954402108', u'view_time': u'1452879954402108'} }}} User agent: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/main.py", line 554, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/main.py", line 267, in dispatch iterable=chrome.use_chunked_encoding) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1075, in render_template stream |= self._filter_stream(req, method, filename, stream, data) File "/usr/local/lib/python2.7/dist- packages/Genshi-0.6-py2.7.egg/genshi/core.py", line 132, in __or__ return Stream(_ensure(function(self)), serializer=self.serializer) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1319, in inner data) File "build/bdist.linux-x86_64/egg/mastertickets/web_ui.py", line 140, in filter_stream field['rendered'] = self._link_tickets(req, data['ticket'][f]) File "build/bdist.linux-x86_64/egg/mastertickets/web_ui.py", line 313, in _link_tickets ticket = Ticket(self.env, tid) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/ticket/model.py", line 69, in __init__ tkt_id = int(tkt_id) ValueError: invalid literal for int() with base 10: '#11238' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 17:55:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 17:55:47 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.d62894cec9d9560b3ea3964f387365cb@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Great! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:00:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:00:04 -0000 Subject: [GHC] #11436: ValueError: invalid literal for int() with base 10: '#11238' In-Reply-To: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> References: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> Message-ID: <062.73d83d58ae65d9608efd48a896d2e7f4@haskell.org> #11436: ValueError: invalid literal for int() with base 10: '#11238' -------------------------------------+------------------------------------- Reporter: trommler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 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: | -------------------------------------+------------------------------------- Comment (by trommler): I looked at #9498 again and it seems links to tickets are back. I have to adjust a few more blockedby fields on other tickets. I'll report back if trac is still acting up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:02:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:02:08 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.7bb49fede2639d20d76f7c81764e7625@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I don't think the `build-man` is getting cleaned now, when running `make clean`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:05:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:05:34 -0000 Subject: [GHC] #11436: ValueError: invalid literal for int() with base 10: '#11238' In-Reply-To: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> References: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> Message-ID: <062.8ee65a536b74b95ed61744660b436376@haskell.org> #11436: ValueError: invalid literal for int() with base 10: '#11238' -------------------------------------+------------------------------------- Reporter: trommler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 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: | -------------------------------------+------------------------------------- Comment (by thomie): Same problem as #10695, different error message? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:13:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:13:00 -0000 Subject: [GHC] #11436: ValueError: invalid literal for int() with base 10: '#11238' In-Reply-To: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> References: <047.fa6050c9a8fa420f978c136c1f675a5e@haskell.org> Message-ID: <062.97554c27309c7667954b51b0a072f9a4@haskell.org> #11436: ValueError: invalid literal for int() with base 10: '#11238' -------------------------------------+------------------------------------- Reporter: trommler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 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: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:2 thomie]: > Same problem as #10695, different error message? I edited ticket #9237 and this time the blockedby field had ticket numbers without hashes but the blocking field had hashes. In that case I ended up getting the same error message as #10695. Note to self: Don't put hashes in front of ticket numbers in ticket blocked/blocking fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:16:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:16:28 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.e4e71009e4f13a319305d2ff8959ee6c@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * blocking: => 9237, 9498 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:17:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:17:25 -0000 Subject: [GHC] #11437: Don't put static (version-based) feature gates in compilerInfo Message-ID: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> #11437: Don't put static (version-based) feature gates in compilerInfo -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 started when someone added `("Support parallel --make", "YES"),`, and then ballooned to a bit more when I added a few more feature gates. I think it's probably wrong for GHC to put feature gates in this structure which are always on or off; Cabal can just version test GHC for appropriate information. (The one benefit of using a feature gate is when you're running a development version of GHC and Cabal, and there is a breakpoint without a version change when a feature is supported). If people agree, we should remove these, and change Cabal to version test to determine if these features are available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:19:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:19:00 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.cd26c35974205b9dd298c5343f80b825@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: simonmar (added) Comment: See [wiki:LinkingHaskell] for design proposal and discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 18:59:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 18:59:14 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.09db12bd8af00695ddecd99fd7744ec9@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 goldfire): Replying to [comment:2 diatchki]: > One (fairly simple?) way for GHC to check the validity of such constraints would be to simply evaluate them until it does find the ground type in question. In your example, this would result in GHC non- terminating during type checking, which is perfectly reasonable, especially since you need `UndecidableInstaces` to write such recursive types. > Except that means that type families can't work over abstract types that we don't know much about yet. For example: {{{ type family Equals a b where Equals a a = True Equals a b = False }}} I `Equals x x` to reduce to `True` even if I don't know what `x` is. Under your scheme, I would need to know what `x` is to be able to make progress, if only to ensure that it terminates. This whole thing is a sad story. But I don't know how to make it better. See also #10327 and [https://typesandkinds.wordpress.com/2015/09/09/what- are-type-families/ my blog post] on the subject ([https://www.reddit.com/r/haskell/comments/3kyfrl/richard_eisenberg_what_are_type_families/ reddit comments on blog post]). Bottom line: I think the Right Solution is to require all non-associated type families to be total (implying terminating) and force all non-total type families to be associated with a class constraint. (This actually makes them functional dependencies in disguise!) Then these problems go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 19:05:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 19:05:56 -0000 Subject: [GHC] #11422: outofmem RTS testcase fails on Windows In-Reply-To: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> References: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> Message-ID: <059.f00c6b03f6660b2d7609ba374890dbd8@haskell.org> #11422: outofmem RTS testcase fails on Windows ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: outpfmem Blocked By: | Blocking: Related Tickets: #11300 | Differential Rev(s): Phab:D1753 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 19:47:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 19:47:02 -0000 Subject: [GHC] #11438: Code does not compile without ScopedTypeVariables Message-ID: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> #11438: Code does not compile without ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Feel free to change the summary, I have no idea how to summarize this issue. The code below fails to compile with `Couldn't match type A with B` and `The function X is applied to one argument, but its type Y has none` and some more (full output is attached below the code). However, simply enabling a language feature (`ScopedTypeVariable`) makes the code compile. If this is not a bug in the compiler then the message should be improved, because nothing in it points to the solution. I always thought of ScopedTypeVariables as allowing me to sprinkle `:: T` throughout the code, in more places than GHC would normally allow. I did not expect that merely enabling this language feature without any other changes in the source code would have any effect on the output. Dependencies: servant, servant-server {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeOperators #-} -- {-# LANGUAGE ScopedTypeVariables #-} module Main where import Data.Proxy import Servant.API import Servant.Server data Credentials = Credential !String instance (HasServer sublayout) => HasServer (Credentials :> sublayout) where type ServerT (Credentials :> sublayout) m = Credentials -> ServerT sublayout m route Proxy subserver request respond = do let mbSessionIdString = lookup "cookie" [("cookie", "session id")] mbCredentials = fmap Credential mbSessionIdString case mbCredentials of Nothing -> error "No credentials supplied" Just cred -> route (Proxy :: Proxy sublayout) (subserver cred) request respond }}} {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:30:60: Couldn't match type ?ServerT sublayout (either-4.4.1:Control.Monad.Trans.Either.EitherT ServantErr IO)? with ?ServerT layout0 (either-4.4.1:Control.Monad.Trans.Either.EitherT ServantErr IO)? NB: ?ServerT? is a type function, and may not be injective The type variable ?layout0? is ambiguous Expected type: Credentials -> Server layout0 Actual type: ServerT (Credentials :> sublayout) (either-4.4.1:Control.Monad.Trans.Either.EitherT ServantErr IO) Relevant bindings include subserver :: Server (Credentials :> sublayout) (bound at Bug.hs:24:17) route :: Proxy (Credentials :> sublayout) -> Server (Credentials :> sublayout) -> Servant.Server.Internal.RoutingApplication (bound at Bug.hs:24:5) The function ?subserver? is applied to one argument, but its type ?Server (Credentials :> sublayout)? has none In the second argument of ?route?, namely ?(subserver cred)? In the expression: route (Proxy :: Proxy sublayout) (subserver cred) request respond Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:11:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:11:42 -0000 Subject: [GHC] #11438: Code does not compile without ScopedTypeVariables In-Reply-To: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> References: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> Message-ID: <065.0d3b824077bfa2b86677777bade2d60e@haskell.org> #11438: Code does not compile without ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This is not a bug, but we could do much better in suggesting `ScopedTypeVariables`. The reason that the change makes a difference is that you refer to the type variable `sublayout` from within a method definition in your instance. You need `ScopedTypeVariables` to bring the instance's type variables into scope. An easy way of suggesting `ScopedTypeVariables` just came to mind: pretend the extension is always on. When looking up a type variable, if the extension is off but the variable would be in scope otherwise, suggest the extension, while returning a lookup failure (because the variable really isn't in scope!). Getting caught on `ScopedTypeVariables` is a fairly common occurrence in my experience, so I think it's worth putting in a bit of effort to do better here. (Even better would be to look for type variables in a signature that's missing a `forall` to suggest adding the `forall`, but that can be a separate task.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.fa239a0e218a381fa726c7eaeee29c96@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e6ca93005bc3df62619f3f968fe51b380e33938a/ghc" e6ca9300/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e6ca93005bc3df62619f3f968fe51b380e33938a" Fix #11355. Previously, the check for impredicative type applications was in the wrong spot. Test case: typecheck/should_fail/T11355 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.05de2a08184d9b508c61b321399832a6@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d4af57fa2a2af0b369087c13c0c7dae869e323bd/ghc" d4af57fa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d4af57fa2a2af0b369087c13c0c7dae869e323bd" Test #11252 in ghci/scripts/T11252 This one worked for me out of the box. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.50a40fbd0dbfb1ff3babd0964ec72a7d@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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 Richard Eisenberg ): In [changeset:"d459f55c36c50ae02c55a7fb1331ef81af6751f5/ghc" d459f55c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d459f55c36c50ae02c55a7fb1331ef81af6751f5" Fix #10872. This moves the duplicate-unique check from knownKeyNames (which omits TH) to allKnownKeyNames (which includes TH). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.e2af60af203411e14641205599fb9a9a@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"3a7f204f5d713ed4ac034d371fc10d8bedb39efa/ghc" 3a7f204f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3a7f204f5d713ed4ac034d371fc10d8bedb39efa" Clarify topological sorting of spec vars in manual This is mentioned in #11376. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:38 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.b17417fdf31dd5f14212d9e0b03a4734@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"80b4c71c5fc8ae005f6fb73d900b225366c4d3cc/ghc" 80b4c71c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80b4c71c5fc8ae005f6fb73d900b225366c4d3cc" Fix typo in error message (#11409) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * In-Reply-To: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> References: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> Message-ID: <062.5c782a7115f9a2ff31b2b2c61f746bde@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6c07f1426e58232092043e28d56717aa489d3670/ghc" 6c07f142/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c07f1426e58232092043e28d56717aa489d3670" Fix #11311 All things of kind *, including * itself, need to have a PtrRep. Test: dependent/should_compile/T11311 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:38 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.5dc3c4194442fc98f5a7a91746768301@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 Richard Eisenberg ): In [changeset:"3c6635ef4561ab53e51d7187c966b628a972b261/ghc" 3c6635ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3c6635ef4561ab53e51d7187c966b628a972b261" Fix #11405. This adds a new variant of AbsBinds that is used solely for bindings with a type signature. This allows for a simpler desugaring that does not produce the bogus output that tripped up Core Lint in ticket #11405. Should make other desugarings simpler, too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.0635017ea85e07bdb1ea0483347afa1d@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"39ea4b4b19ea65d05f0d946084b316d5f5d2e675/ghc" 39ea4b4b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="39ea4b4b19ea65d05f0d946084b316d5f5d2e675" Fix #11254. This moves the call to tcSubType into the context of the checkInstConstraints call, allowing the deferred type error somewhere to hang its hat. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11404: The type variable used in a kind is still used In-Reply-To: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> References: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> Message-ID: <062.834220de7c0191a94489589d2b5a1de8@haskell.org> #11404: The type variable used in a kind is still used -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"072191fe2db55eb3ede5d5a90b7f5eb6afde25bc/ghc" 072191fe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="072191fe2db55eb3ede5d5a90b7f5eb6afde25bc" Fix #11404 We now check for unused variables one at a time, instead of all at the top. Test: dependent/should_compile/T11405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:43:37 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.6f66733825776970650beb3ee915efce@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 Richard Eisenberg ): In [changeset:"bafbde7e239dd7353fb32cb2ff1b1c9139e4f45c/ghc" bafbde7e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bafbde7e239dd7353fb32cb2ff1b1c9139e4f45c" Constrained types have kind * in validity check. This addresses #11405, but a deeper problem lurks. Try test dependent/should_compile/T11405 and see comment:3 on the ticket. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:45:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:45:37 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.cc0c22780fa2726d40b76157476dd40f@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11355 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T11355 * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:47:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:47:10 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.bb989bbf0f900dc12f9bdf9fc583e4c7@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Please merge the above commit to 8.0. Not setting "merge" status on the ticket because the bigger problem is not yet solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:47:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:47:51 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * In-Reply-To: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> References: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> Message-ID: <062.f9b64954a9af82d90acbaed8e9e45f52@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_compile/T11311 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => dependent/should_compile/T11311 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:48:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:48:44 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.8b152911df54a08919709b2fd1917de3@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * milestone: => 8.0.1 Comment: It's just the test case that I added. But that should be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:49:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:49:19 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.d571a253115d044041a6e90e8d27b668@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire Type: task | Status: closed Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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 goldfire): * status: new => closed * resolution: => fixed Comment: This is just a debugging aid. No crying need to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:50:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:50:02 -0000 Subject: [GHC] #11404: The type variable used in a kind is still used In-Reply-To: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> References: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> Message-ID: <062.aa60119c69673ca8cdbc30955f643de1@haskell.org> #11404: The type variable used in a kind is still used -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T11405 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T11405 * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:50:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:50:30 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.086772619ec9ea14e8d48cb98027d86d@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Do please merge the typo fix above. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:50:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:50:57 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.a9f1ff34b1cabad985970347feef0b3d@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:51:04 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.20dc29af544f5cc3a909c5f18d77928a@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:51:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:51:45 -0000 Subject: [GHC] #11438: Code does not compile without ScopedTypeVariables In-Reply-To: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> References: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> Message-ID: <065.7c9877732adea13a4896585c227d01b1@haskell.org> #11438: Code does not compile without ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by bgamari): We should also mention in the users guide the fact that type variables in an instance head are brought into scope. [[http://downloads.haskell.org/~ghc/master/users- guide//glasgow_exts.html?highlight=scoped%20type%20variables#ghc-flag-- XScopedTypeVariables|Currently]] the text suggests that only variables introduced with an explicit `forall` are brought into scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:51:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:51:55 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.8bcb2e6e400941d1025648d60cacaf23@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T11405 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T11405 * status: new => merge Comment: This one is finally put to rest. Unwiring `undefined` should now work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 20:52:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 20:52:57 -0000 Subject: [GHC] #11438: Code does not compile without ScopedTypeVariables In-Reply-To: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> References: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> Message-ID: <065.692cfd3d0b70c6fbe0290b8d1f0d7854@haskell.org> #11438: Code does not compile without ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh, never mind, you just need to read farther than the first two paragraphs of the section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 21:39:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 21:39:11 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.1dcb7afc53fda4be36622abe65df8eb9@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): As `Note [Type constructors in export list]` says, type/variable constructors in export lists introduce ambiguity in grammar: {{{ Mixing type constructors and variable constructors in export lists introduces ambiguity in grammar: e.g. (*) may be both a type constuctor and a function. -XExplicitNamespaces allows to disambiguate by explicitly prefixing type constructors with 'type' keyword. This ambiguity causes reduce/reduce conflicts in parser, which are always resolved in favour of variable constructors. To get rid of conflicts we demand that ambigous type constructors (those, which are formed by the same productions as variable constructors) are always prefixed with 'type' keyword. Unambigous type constructors may occur both with or without 'type' keyword. }}} Resolving ambiguity by changing grammar is impractical: type/variable constructors in export lists are used in exactly the same context (it's *not* a lookahead problem). This ambiguity can be resolved, but not on parser level: parser should parse constructor as 'just some constructor' (wrap it) and delay the actual decision to the next phase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 21:41:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 21:41:10 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.c8b9d165379618cee036e5e1a81eac8d@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 diatchki): I am not sure what you mean by "abstract types". If by `x` you mean a type variable, then I don't think there is any problem in reducing `Equals x x` to `True`. Otoh, if you encountered `Equals (F a) (F a)`, then you can still reduce that to `True`, but you'd also have to emit the constraint `F a ~ b`, to make sure that `F a` is well-defined. I do agree that if we can't prove that a type family is total, it essentially should have a well-formedness check on every use---in this example this is `F a ~ b`, but one may have some other class/constraint encoding the same thing too. One may also think of this the other way: we always emit a well-formedness constraint on use, but if we've proved that a type function is total, then we can solve this constraint trivially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 21:53:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 21:53:08 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.8b54abf247f1feadf0f419cb9a4a0d8d@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 goldfire): Replying to [comment:4 diatchki]: > If by `x` you mean a type variable, then I don't think there is any problem in reducing `Equals x x` to `True`. > > Otoh, if you encountered `Equals (F a) (F a)`, then you can still reduce that to `True`, but you'd also have to emit the constraint `F a ~ b`, to make sure that `F a` is well-defined. > But this doesn't support the substitution lemma. You say that we can reduce `Equals x x`. But what if we later learn that `x` is really `F a`? So if we're going to do the well-definedness check in the `F a` case, we have to delay reducing the `x` case. I agree with the other points in comment:4. Instead of a general well- formedness check, I'm asking the users to provide the name of a class that represents well-formedness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 21:53:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 21:53:51 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.56f73927ba0367b56f95d332612c896b@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): I will try to get to that this weekend or early next week at the latest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 22:10:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 22:10:32 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.c4a1f1b1c5be7b4d4218e88f5e8d34c6@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): The fact that GHC handled this ambiguous case correctly suggests that it already has this wrapping-delaying mechanism (because happy-generated parser always resolved the ambiguity in favor of variable constructor, which in this case is incorrect). I'll try to find out how it worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 22:59:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 22:59:30 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.2d87706f32bd91b79713668397a85c37@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): Turns out I was wrong in thinking that variable/type constructors appear in the same context: `(..)` is only allowed after type constructors (so goldfire was right about parenthesis and lookahead). GHC grammar allows invalid syntax like `(..)` after variable constructors: https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/parser/Parser.y#L633 {{{ export :: { OrdList (LIE RdrName) } : qcname_ext export_subspec {% mkModuleImpExp $1 (snd $ unLoc $2) ... }}} `qcname_ext` here can be both variable/type constructor, and `export_subspec` can be `(..)`. This can (and should) be fixed in grammar so that non-ambiguous constructs like `(-.->)(..)` in export lists are accepted without `type` keyword. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 23:39:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 23:39:17 -0000 Subject: [GHC] #11427: superclasses aren't considered because context is no smaller than the instance head In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.642e2025a0eb3de95b4c46cf037ef3a6@haskell.org> #11427: superclasses aren't considered because context is no smaller than the instance head -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 agree that the error message could be better, but I don't see an easy way to ''make'' it better. All the error-message generator sees is that `(SListI xss)` is unsolved. It hard for it to figure out that it might have been solved from superclasses but in fact wasn't because of size. The "arising from" is easier to improve perhaps. What should it say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 23:44:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 23:44:55 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures Message-ID: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Interested in feedback (Code inspired by [http://www.cs.ox.ac.uk/projects/utgp/school/idris-tutorial.pdf Idris tutorial]) {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum STrue x = x sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Allow duplicate type signatures: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum :: SBool True -> Natural -> Natural sum STrue x = x sum :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} Where {{{#!hs data SBool b where STrue :: SBool True SFalse :: SBool False type family IsSingleton (b :: Bool) :: Type where IsSingleton True = Natural IsSingleton False = [Natural] }}} ---- == Behaviour == You could do something fancy but I would be happy with a check that any duplicate type signature is a specialization of the ''top'' top-level one, this would allow something like this: {{{#!hs length :: [a] -> Int length :: [()] -> Int length [] = 0 length (_:xs) = 1 + length xs }}} Which isn't very useful, hah what ever. ---- == Benefits == Mainly compiler-checked documentation, for the `sum` function we make it clearer that a `STrue` gives you `Natural -> Natural` while `SFalse` gives you `[Natural] -> Natural`. This is most apparent in the final syntax idea: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural @False :: _ -> [Natural] -> Natural }}} Reader need not look at definition of `IsSingleton`, it is fully described by the duplicate signatures. See ''lens'' where most functions have some kind of type specialisation declared in comments: [https://hackage.haskell.org/package/lens-4.13/docs /Control-Lens-Fold.html#v:-94--63- (^?)] whose type is `(^?) :: s -> Getting (First a) s a -> Maybe a`: {{{#!hs (^?) :: s -> Getter s a -> Maybe a (^?) :: s -> Fold s a -> Maybe a (^?) :: s -> Lens' s a -> Maybe a (^?) :: s -> Iso' s a -> Maybe a (^?) :: s -> Traversal' s a -> Maybe a }}} ---- == Alternative syntax == Throwing it out there, regardless of ambiguity: {{{#!hs sum :: SBool single -> IsSingleton single -> Natural :: SBool True -> Natural -> Natural sum STrue x = x :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... :: SBool True -> Natural -> Natural sum STrue x = x ... :: SBool False -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural ... @True :: _ -> Natural -> Natural sum STrue x = x ... @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} or {{{#!hs sum :: SBool single -> IsSingleton single -> Natural @True :: _ -> Natural -> Natural sum STrue x = x @False :: _ -> [Natural] -> Natural sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 23:46:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 23:46:21 -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.514b7a5ef22b32e787aee7e693b590a2@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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 jbracker): * Attachment "core-error.zip" removed. File of the core warning example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 15 23:46:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jan 2016 23:46:22 -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.7445f6aec659f83bce280e71570f186d@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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 jbracker): * Attachment "core-error.zip" added. Files of the core warning example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 00:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 00:30:53 -0000 Subject: [GHC] #11440: GHC.Prim does not export Constraint Message-ID: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> #11440: GHC.Prim does not export Constraint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 code from the `effect-monad` library worked in ghc-7.10, but fails with ghc-8.0.1-rc1: {{{ {-# LANGUAGE TypeFamilies, ConstraintKinds, PolyKinds #-} module Control.Effect.Cond where import GHC.Prim class Cond (m :: k -> * -> *) where type AltInv m (s :: k) (t :: k) :: Constraint }}} It seems one now needs to import `Constraint` from `GHC.Exts`. This should be mentioned in the migration guide (https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0), together with any other breaking changes there might be from the kind equalities patch (6746549772c5cc0ac66c0fce562f297f4d4b80a2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 01:39:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 01:39:40 -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.f1d45430ac4f90ed7df977786431b50d@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This thread sheds some light: https://mail.haskell.org/pipermail/ghc- devs/2015-November/010513.html Given that this ticket is the same issue as the one you raised there, it would be helpful for you to include that link when posting. I notice that the problem occurs in the result of the simplifier. Could it be coercion optimization? Try with `-fno-opt-coercion`. Also, try with `-O0`. Does `-fprint-explicit-kinds -fprint-explicit-foralls` change the output? The report is made against GHC 7.10.2. Is that accurate? Has anyone reproduced with HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 01:45:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 01:45:02 -0000 Subject: [GHC] #11440: GHC.Prim does not export Constraint In-Reply-To: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> References: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> Message-ID: <060.767e6778b2dd65880fa83b3bbcea07af@haskell.org> #11440: GHC.Prim does not export Constraint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): As I understand it, `GHC.Exts` is the One Official Place from where to import magic GHC gubbins, so I didn't worry too much about moving things around behind the scenes. I'll add a note to the migration guide. There should not be other breakages from the kind equalities patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 01:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 01:49:29 -0000 Subject: [GHC] #11440: GHC.Prim does not export Constraint In-Reply-To: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> References: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> Message-ID: <060.ef96d998be011b04a4b2fd34163a60d8@haskell.org> #11440: GHC.Prim does not export Constraint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 goldfire): * status: new => closed * resolution: => fixed Comment: Updated the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 01:51:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 01:51:36 -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.05d1bf315ddce3648a213a0d903905ba@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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: | -------------------------------------+------------------------------------- Comment (by thomie): `-fno-opt-coercion` makes the problem go away. Tested with ghc-7.10.3. The plugin doesn't compile with GHC 8 or HEAD, without significant changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 01:59:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 01:59:11 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.a9a1ddbad715ede0dff8775599025e64@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I do think something like this would be useful. But recall that type signatures and function definitions need not be next to each other. And I'm very suspicious of a proposal that cares about top-to-bottom ordering of definitions (nowhere else in Haskell is that done). On the other hand, this is a good idea for a pragma. Perhaps {{{ foo :: a -> a foo x = x {-# TYPECHECK foo :: Bool -> Bool foo :: Int -> Int foo :: Maybe a -> Maybe a foo True :: Bool map id [] #-} }}} The idea here is that the `TYPECHECK` pragma allows to you list a bunch of expressions. GHC checks that the expressions are well-typed. If one isn't, an error is issued. You could imagine Haddock looking for examples where the expression is a type signature for a bare variable and then using the types as extra documentation for that variable. While we're at it, I'd also love {{{ {-# ILL_TYPED map True False - 'x' #-} }}} If an expression in `ILL_TYPED` is actually well-typed, an error is issued. This would be very useful in putting in unit tests for fancy type- level features. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 02:03:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 02:03:31 -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.22c13d6ccb3f5ce0ed0cbb3727bb831d@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Drat. Sounds like a proper GHC bug. Post the output with `-fprint-explicit-kinds -fprint-explicit-foralls -ddump-tc -ddump-tc-trace -dverbose-core2core`. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 11:46:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 11:46:54 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.83a258ef72b66db417549ef5a8bfbbdb@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 12:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 12:47:58 -0000 Subject: [GHC] #11405: Incorrect failure of type-level skolem escape check In-Reply-To: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> References: <047.b0d93bb597cf708c3b927488a8292cea@haskell.org> Message-ID: <062.8f0f8a4b11816810b08b09198b068a2a@haskell.org> #11405: Incorrect failure of type-level skolem escape check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T11405 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Old description: > From Phab:D1739. > > When you say > > {{{ > undefined :: forall (v :: Levity). forall (a :: TYPE v). (?callStack :: > CallStack) => a > }}} > > you get a skolem escape failure because GHC things that the kind of > `(?callStack :: CallStack) => a` is `TYPE v`. It should be `*`. > > I will fix. New description: From Phab:D1739. When you say {{{#!hs undefined :: forall (v :: Levity). forall (a :: TYPE v). (?callStack :: CallStack) => a }}} you get a skolem escape failure because GHC things that the kind of `(?callStack :: CallStack) => a` is `TYPE v`. It should be `*`. I will fix. -- Comment: This has been merged to `ghc-8.0` as 018f866. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 13:52:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 13:52:49 -0000 Subject: [GHC] #11430: ApiAnnotations: work SourceText in for all integer literals In-Reply-To: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> References: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> Message-ID: <059.2a752708fd39d57b5b089817e0330641@haskell.org> #11430: ApiAnnotations: work SourceText in for all integer literals -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"3a1babd6243edd96073ed3e3a5fb6e0aaf11350e/ghc" 3a1babd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3a1babd6243edd96073ed3e3a5fb6e0aaf11350e" Work SourceText in for all integer literals Summary: Certain syntactic elements have integers in them, such as fixity specifications, SPECIALISE pragmas and so on. The lexer will accept mult-radix literals, with arbitrary leading zeros in these. Bring in a SourceText field to each affected AST element to capture the original literal text for use with API Annotations. Affected hsSyn elements are ``` -- See note [Pragma source text] data Activation = NeverActive | AlwaysActive | ActiveBefore SourceText PhaseNum -- Active only *strictly before* this phase | ActiveAfter SourceText PhaseNum -- Active in this phase and later deriving( Eq, Data, Typeable ) -- Eq used in comparing rules in HsDecls data Fixity = Fixity SourceText Int FixityDirection -- Note [Pragma source text] deriving (Data, Typeable) ``` and ``` | HsTickPragma -- A pragma introduced tick SourceText -- Note [Pragma source text] in BasicTypes (StringLiteral,(Int,Int),(Int,Int)) -- external span for this tick ((SourceText,SourceText),(SourceText,SourceText)) -- Source text for the four integers used in the span. -- See note [Pragma source text] in BasicTypes (LHsExpr id) ``` Updates haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1781 GHC Trac Issues: #11430 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 13:55:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 13:55:02 -0000 Subject: [GHC] #11430: ApiAnnotations: work SourceText in for all integer literals In-Reply-To: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> References: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> Message-ID: <059.384b5c7cc800c4e81181eb531cdae381@haskell.org> #11430: ApiAnnotations: work SourceText in for all integer literals -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 15:55:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 15:55:02 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) Message-ID: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Allow intermediate code inline. == Inline ''Core'' == Typeable/WithTypeable: > {{{#!hs > withTypeable :: TTypeRep a -> (Typeable a => r) -> r > }}} > > Currently, `withTypeable` cannot be written in Haskell, but it is straightforward to write in Core. Can we fix this? [http://www.seas.upenn.edu/~sweirich/papers/wadlerfest2016.pdf A reflection on types] (''2016''): > We cannot implement ''withTypeable'' in Haskell source. But we ''can'' implement it in GHC's statically-typed intermediate language, System FC. The definition is simple, roughly like this: > > {{{#!hs > withTypeable tr k = k tr -- Not quite right > }}} > > Its second argument ''k'' expects a ''Typeable'' dictionary as its value argument. But since > a ''Typeable'' dictionary is represented by a ''TypeRep'', we can simply pass ''tr'' to ''k''. > When written in System FC there is a type-safe coercion to move from ''TypeRep a'' to ''Typeable a'', > but that coercion is erased at runtime. Since the definition can be statically type checked, > ''withTypeable'' does not form part of the trusted code base. == Inline ''Cmm'' == Edkward Kmett writes his own `.cmm` [https://github.com/ekmett/concurrent/blob/master/cbits/hashmap.cmm hither], [https://github.com/ekmett/concurrent/blob/master/cbits/array.cmm yon]. == Inline ''Strict Core'' == Should [http://research.microsoft.com/en-us/um/people/simonpj/papers /strict-core/tacc-hs09.pdf Types are calling conventions] (''2009'') be implemented: > === '''4.4 The ''`seq`'' function''' === > > A nice feature of Strict Core,,ANF,, is that it is possible to give a straightforward definition of the primitive ''seq'' function of Haskell: > {{{#!hs > seq : {a:* -> b:* -> {a} -> {b} -> b} > = { \a:*. \b:*. \x:{a}. \y:{b}. let _:a = x <> in y <> } > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 16:12:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 16:12:57 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.a3aac7e5072a26aa5eace07747854ede@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I like that, GHCi could display associated types: {{{#!hs >>> :type sum sum :: SBool single -> IsSingleton single -> Natural >>> >>> :types sum sum :: SBool single -> IsSingleton single -> Natural sum STrue :: Natural -> Natural sum SFalse :: [Natural] -> Natural }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 16:24:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 16:24:49 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.4449cb0bfb7d55ff6c8384a81317b7be@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It would also help simplify the FTP types, as well as showing possibly enlightening groupings (`(a -> b) -> (F a -> F b)` versus `(a -> b) -> F a -> F b`): {{{#!hs >>> :types length length :: Foldable t => t a -> Int length :: [a] -> Int length :: Set a -> Int length :: Map k v -> Int }}} {{{#!hs >>> :types fmap fmap :: Functor f => (a -> b) -> f a -> f b fmap :: Functor f => (a -> b) -> (f a -> f b) fmap :: (a -> b) -> ([a] -> [b]) fmap :: (a -> b) -> (Either e a -> Either e b) fmap :: (b -> c) -> (a -> b) -> (a -> c) }}} {{{#!hs >>> :types sequence sequence :: (Traversable t, Monad m) => t (m a) -> m (t a) sequence :: Monad m => [m a] -> m [a] sequence :: [IO a] -> IO [a] sequence :: [Maybe a] -> Maybe [a] sequence :: [r -> a] -> (r -> [a]) sequence :: [[a]] -> [[a]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 16:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 16:51:50 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.24a2dce3007a45eac249ddf27a319401@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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 adamgundry): * cc: adamgundry (added) Comment: I'm not really convinced by the original ticket: couldn't you just as well do something like {{{#!hs sum :: SBool single -> IsSingleton single -> Natural sum STrue = sumTrue sum SFalse = sumFalse sumTrue :: Natural -> Natural sumTrue x = x sumFalse :: [Natural] -> Natural sumFalse [] = 0 sumFalse (x : xs) = x + sumFalse xs }}} without needing any additional syntax or rules for associating duplicate signatures with parts of definitions? On the other hand, being able to declare a bunch of specializations such that GHCi or Haddock can display them does seem rather useful, especially for the kind of very polymorphic code you get in `lens` or the post-FTP Prelude. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:06:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:06:34 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.104e6df6a05dd837d9699d6f5b0c4af9@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Cherry-picked to `ghc-8.0` as b7af30f79f7e3be105cdd17ee3369a5e483f7f3f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:07:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:07:12 -0000 Subject: [GHC] #11404: The type variable used in a kind is still used In-Reply-To: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> References: <047.5f9881c2ddbb4323cac9e513c96e2b2b@haskell.org> Message-ID: <062.c8f3a19f4dec64a429b7ca0ed8d16f7a@haskell.org> #11404: The type variable used in a kind is still used -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T11405 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Cherry-picked to `ghc-8.0` as a5bb4809614b6f898384c02c6e00d92fd0f5d7c4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:07:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:07:52 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.341a57fc86ae2927425e2d4bf4dee175@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Cherry-picked to `ghc-8.0` as 4c53ab2a108a749ae45657c73cda233b528fb029. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:08:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:08:21 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * In-Reply-To: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> References: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> Message-ID: <062.b972e75b1e72ac58e20c9cd6b26d4b58@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_compile/T11311 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Cherry-picked to `ghc-8.0` as 7e58aa08be2e58d0748c89fe7fad2c0961a35083. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:09:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:09:35 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.3247195669d01f226eedb4f3235dea19@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire Type: task | Status: closed Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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 bgamari): Cherry-picked to `ghc-8.0` as a1a054b1c91a4dc234d879064a0612eefdcd3fcf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:09:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:09:58 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.14c331ca5dd722620f4f479e41caaab0@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11355 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Cherry-picked to `ghc-8.0` as d4661c1adc732b12d39a6aab4a3f5a8c61e27dde. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 17:10:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 17:10:03 -0000 Subject: [GHC] #11355: TypeApplications + RankNTypes permits "impredicativity" In-Reply-To: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> References: <049.e21d55a7ad6ad6c897f56ce3fe5605e6@haskell.org> Message-ID: <064.2f00a4e86e416099fe823004d045ed40@haskell.org> #11355: TypeApplications + RankNTypes permits "impredicativity" -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11355 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 19:02:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 19:02:58 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.e937497591dfb0c49d223c74acc3482c@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => new * owner: goldfire => * resolution: fixed => Comment: Thanks for merging the typo fix. But that's nowhere near the nub of this ticket. We might well decide to do nothing, but I'm not convinced we've converged on that solution yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 19:05:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 19:05:10 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.69813df4083b6f3731d33fb18c89f038@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this would be quite useful. And quite a lot of work. Are you volunteering to do it? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 21:19:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 21:19:01 -0000 Subject: [GHC] #11442: Segfault when showing (undefined :: Type) Message-ID: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> #11442: Segfault when showing (undefined :: Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This [https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 comment] made me wonder about the relationship between `Void` and `Type`, `id :: Void -> Void` and `id :: Type -> Type`: https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 {{{#!hs {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #- import Data.Kind (Type) instance Show Type where show _ = "..." main = print (undefined :: Type) }}} running gives: {{{ $ runghc --version runghc 8.1.20160113 $ runghc -ignore-dot-ghci Segfault.hs Segmentation fault (core dumped) }}} Verbose log attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 21:19:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 21:19:43 -0000 Subject: [GHC] #11442: Segfault when showing (undefined :: Type) In-Reply-To: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> References: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> Message-ID: <066.79a60723f51e2d0f90d8d5244d08edb9@haskell.org> #11442: Segfault when showing (undefined :: Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Segfault.log" added. runghc -v3 -ignore-dot-ghci /tmp/Segfault.hs &> /tmp/Segfault.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 21:23:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 21:23:28 -0000 Subject: [GHC] #8114: STG lint panic In-Reply-To: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> References: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> Message-ID: <070.38dba61082e53046841413ee1073052f@haskell.org> #8114: STG lint panic -------------------------------------+------------------------------------- Reporter: Ptharien's Flame | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5345 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Apart from the STG lint issue (which I really can't comment on), it's not clear to me why `text` is using `unsafeCoerce#` here instead of `unfreezeByteArray#`, which seems to pre-date `Data.Text.Array`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 21:44:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 21:44:39 -0000 Subject: [GHC] #8114: STG lint panic In-Reply-To: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> References: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> Message-ID: <070.b8c1df823189417ae8800bd4ee0b0256@haskell.org> #8114: STG lint panic -------------------------------------+------------------------------------- Reporter: Ptharien's Flame | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5345 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed reworking the code in question to use `unsafeFreezeByteArray#` resolves the STG lint violation. I've opened a [[https://github.com/bos/text/pull/144|pull request]] against `text` fixing this. Given that this issue is only observed with `unsafeCoerce#` and STG linting is already a bit sketchy, I'm going to close this as won't fix. Thanks for your report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 21:44:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 21:44:46 -0000 Subject: [GHC] #8114: STG lint panic In-Reply-To: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> References: <055.f8c8a84c7f414e985f0ca544eba21760@haskell.org> Message-ID: <070.d36fa6491e51441c398afa34817bb927@haskell.org> #8114: STG lint panic -------------------------------------+------------------------------------- Reporter: Ptharien's Flame | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5345 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 22:02:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 22:02:34 -0000 Subject: [GHC] #11442: Segfault when showing (undefined :: Type) In-Reply-To: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> References: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> Message-ID: <066.0596bd9ae1c2c9b1822c5b7e891046e2@haskell.org> #11442: Segfault when showing (undefined :: Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This was fixed yesterday. (Dup of #11311). In answer to your question: `Void` and `Type` are both (currently) empty in terms. But `Void` is also empty in types, whereas `Type` is (obviously) not. Do not use `Type` as a substitution for `Void`, please, though, as the long-term plan includes inhabiting `Type` in terms. After all, `Type` and `TypeRep` really should be the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 22:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 22:06:17 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.d6ab89939679c0e44c2a8974b6767c35@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe Phab:D1786 will fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 22:44:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 22:44:27 -0000 Subject: [GHC] #11408: Delicate solve order In-Reply-To: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> References: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> Message-ID: <061.8c025ae747efcf6d9d95746381a775f9@haskell.org> #11408: Delicate solve order -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9308c736d43b92bf8634babf565048e66e071bd8/ghc" 9308c736/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9308c736d43b92bf8634babf565048e66e071bd8" Fix a number of subtle solver bugs As a result of some other unrelated changes I found that IndTypesPerf was failing, and opened Trac #11408. There's a test in indexed-types/should-compile/T11408. The bug was that a type like forall t. (MT (UL t) (UR t) ~ t) => UL t -> UR t -> Int is in fact unambiguous, but it's a bit subtle to prove that it is unambiguous. In investigating, Dimitrios and I found several subtle bugs in the constraint solver, fixed by this patch * canRewrite was missing a Derived/Derived case. This was lost by accident in Richard's big kind-equality patch. * Interact.interactTyVarEq would discard [D] a ~ ty if there was a [W] a ~ ty in the inert set. But that is wrong because the former can rewrite things that the latter cannot. Fix: a new function eqCanDischarge * In TcSMonad.addInertEq, the process was outright wrong for a Given/Wanted in the (GWModel) case. We were adding a new Derived without kicking out things that it could rewrite. Now the code is simpler (no special GWModel case), and works correctly. * The special case in kickOutRewritable for [W] fsk ~ ty, turns out not to be needed. (We emit a [D] fsk ~ ty which will do the job. I improved comments and documentation, esp in TcSMonad. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 23:30:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 23:30:13 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.402ec779ffff3e01d4870650922467f9@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11422 | Differential Rev(s): Phab:D1787 Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1787 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 16 23:55:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jan 2016 23:55:34 -0000 Subject: [GHC] #11408: Delicate solve order In-Reply-To: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> References: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> Message-ID: <061.5fa45f9d47bd61ff7fdd4222a1bd571b@haskell.org> #11408: Delicate solve order -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T11408 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T11408 * resolution: => fixed Old description: > Should we successfully infer a type for `f`: > {{{ > f x = [h x, [x]] > }}} > assuming `h :: forall b. F b -> b`? > > Assuming `(x::alpha)` and we instantiate `h` at `beta`, we get the > constraints > {{{ > (1) beta ~ [alpha] from the list [h x, [x]] > (2) alpha ~ F beta from the call of h > }}} > Now if we happen to unify the constraint (1) first, `beta := [alpha`], > then we successfully infer > {{{ > f :: forall a. (a ~ F [a]) => a -> [[a]] > }}} > But if we unify the constraint (2) first, `alpha := F beta`, we get > {{{ > f :: forall b. (b ~ [F b]) => F b -> [[F b]] > }}} > which is ambiguous. > > Eeek! This actually shows up in type inference for `indexed- > types/should_compile/IndTypesPerfMerge`, where the function `merge` has > (a slightly more complicated form of) this delicately-balanced situation. > > But see `Note [Orientation of equalities with fmvs]` in `TcFlatten` for > why we don't defer solving (2). New description: Should we successfully infer a type for `f`: {{{ f x = [h x, [x]] }}} assuming `h :: forall b. F b -> b`? Assuming `(x::alpha)` and we instantiate `h` at `beta`, we get the constraints {{{ (1) beta ~ [alpha] from the list [h x, [x]] (2) alpha ~ F beta from the call of h }}} Now if we happen to unify the constraint (1) first, `beta := [alpha`], then we successfully infer {{{ f :: forall a. (a ~ F [a]) => a -> [[a]] }}} But if we unify the constraint (2) first, `alpha := F beta`, we get {{{ f :: forall b. (b ~ [F b]) => F b -> [[F b]] }}} which looks ambiguous. It isn't ambiguous, in fact, but the solver has to work hard to prove it. It actually succeeds here, but in the more complicated example in `indexed-types/should_compile/IndTypesPerfMerge`, it didn't. There the function `merge` has (a slightly more complicated form of) this delicately-balanced situation. But see `Note [Orientation of equalities with fmvs]` in `TcFlatten` for why we don't defer solving (2). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 01:59:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 01:59:15 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 Message-ID: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 -- where main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 02:00:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 02:00:05 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.dc6d41f9cbed7e3de159234c4d63893b@haskell.org> #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 ---------------------------------+---------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2): * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 02:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 02:01:29 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.b5410700abc456cb7e782c20cdf6d6a1@haskell.org> #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 ---------------------------------+---------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: | ---------------------------------+---------------------------------------- Description changed by danilo2: Old description: > Hello! > I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` > pragma works, but if I understand correctly, then there is a bug in GHC. > Lets consider this simple code: > > module `A`: > > {{{ > > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleInstances #-} > > module A where > > import Prelude > import GHC.TypeLits > > -- TF utils > > type family (a :: Nat) :== (b :: Nat) where > a :== a = 'True > a :== b = 'False > > type family If cond (a :: Nat) (b :: Nat) where > If 'True a b = a > If 'False a b = b > > -- Heavy TF computations > > type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 > HeavyTF n i = If > (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 > > type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 > HeavyTF' n = HeavyTF' (n - > 1) > > -- Params for tests (bigger numbers = longer compile times) > > type family NatOf a :: Nat > type instance NatOf Int = 12000 > type instance NatOf String = 12000 > > -- Type class to check GHC behavior > class PerfC1 a where perfc1 :: a -> String > instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" > ; {-# INLINABLE perfc1 #-} > > class CheckOk (n :: Nat) > instance CheckOk 0 -- where > > main_cache :: IO () > main_cache = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > > perfc1_Int :: Int -> String > perfc1_Int = perfc1 > > perfc1_String :: String -> String > perfc1_String = perfc1 > > {-# SPECIALIZE perfc1 :: Int -> String #-} > {-# SPECIALIZE perfc1 :: String -> String #-} > > ----- > > perfc1' :: PerfC1 a => a -> String > perfc1' = perfc1 > {-# INLINABLE perfc1' #-} > > {-# SPECIALIZE perfc1' :: Int -> String #-} > {-# SPECIALIZE perfc1' :: String -> String #-} > > }}} > > module `Test1`: > > {{{ > import A > > main = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > }}} > > module `Test2`: > > {{{ > import A > > main = do > print $ perfc1' (1 :: Int) > print $ perfc1' ("a" :: String) > }}} > > module `Test3`: > > {{{ > import A > > main = do > print $ perfc1_Int (1 :: Int) > print $ perfc1_String ("a" :: String) > }}} > > Compile with: > `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` > `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 > Test.hs` > > If module `A` was already compiled the compilation times for `ghc 7.10.3` > were as follow: > - `Test1`: ~ 16s > - `Test2`: ~ 16s > - `Test3`: almost instant > > And for `ghc 8.0-rc1` were as follow: > - `Test1`: ~ 28s > - `Test2`: ~ 28s > - `Test3`: almost instant > > Here are 2 bugs to note: > > 1) the compilation times are much longer with new GHC > > 2) the specialize pragmas do not work New description: Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 -- where main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` (I've used `-fenable-rewrite-rules` explicitly just to be sure it is enabled. We can omit it because `-O2` enables it) If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 02:01:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 02:01:46 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.82719859fd047012690db721c9da1d92@haskell.org> #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2): * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 02:03:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 02:03:25 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 (was: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1) In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.0c3c2ea3ea6a6bf14c482c9d99c0083c@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:00:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:00:16 -0000 Subject: [GHC] #10921: weird "optimisation levels" in man page In-Reply-To: <043.8680f4d8778862d9aa62137f8695f078@haskell.org> References: <043.8680f4d8778862d9aa62137f8695f078@haskell.org> Message-ID: <058.31ed149deb1ae7f35dfa7df4fc82bd54@haskell.org> #10921: weird "optimisation levels" in man page -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: manpage, | 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 thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This was fixed by bgamari. {{{ Optimization levels -O0 -O, -O1 -O2 -Odph }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:20:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:20:48 -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.d41efdb391255f9a25a211064cfc3799@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 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 danilo2: Old description: > If a function marked as `INLINABLE` is called indirectly through a simple > wrapper defined in a different module, specialization never happens (i.e. > none of the dictionaries are removed.) > > Here's an example where it fails. First, the simple wrapper module: > > {{{ > module Repro where > > import Data.Hashable > import Data.HashMap.Strict as M > > infixl 9 ! > (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b > m ! x = case M.lookup x m of -- lookup is INLINABLE > Just y -> y > Nothing -> error "Repro.!" > }}} > > and then the call site: > > {{{ > module Test (test) where > > import Data.HashMap.Strict as M > > import Repro > > test :: M.HashMap Int Int -> Int > test m = m ! 42 > }}} > > To compile the code you need to `cabal install unordered-containers`. The > relevant function (which is not getting specialized) from unordered- > containers is: > > {{{ > lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v > lookup k0 = go h0 k0 0 > where > h0 = hash k0 > go !_ !_ !_ Empty = Nothing > go h k _ (Leaf hx (L kx x)) > | h == hx && k == kx = Just x > | otherwise = Nothing > go h k s (BitmapIndexed b v) > | b .&. m == 0 = Nothing > | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex > b m)) > where m = mask h s > go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) > go h k _ (Collision hx v) > | h == hx = lookupInArray k v > | otherwise = Nothing > #if __GLASGOW_HASKELL__ >= 700 > {-# INLINABLE lookup #-} > #endif > }}} > > If `test` calls `lookup` directly, without using the `(!)` wrapper, > things get specialized. Manually marking `(!)` as `INLINABLE` works, but > users shouldn't have to do that. > > The core for `Repro` and `Test` is: > > {{{ > $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl > [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) > > ==================== Tidy Core ==================== > Result size = 28 > > lvl_rNZ :: [GHC.Types.Char] > [GblId] > lvl_rNZ = GHC.CString.unpackCString# "Repro.!" > > Repro.!1 :: forall b_aBU. b_aBU > [GblId, Str=DmdType b] > Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ > > Repro.! > :: forall a_atJ b_atK. > (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => > Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK > [GblId, > Arity=4, > Str=DmdType LLLL, > Unf=Unf{Src=, TopLvl=True, Arity=4, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0 0 0 0] 70 0}] > Repro.! = > \ (@ a_aBT) > (@ b_aBU) > ($dEq_aBV :: GHC.Classes.Eq a_aBT) > ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) > (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) > (x_atM :: a_aBT) -> > case Data.HashMap.Base.lookup > @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL > of _ { > Data.Maybe.Nothing -> Repro.!1 @ b_aBU; > Data.Maybe.Just y_atN -> y_atN > } > > > [2 of 2] Compiling Test ( Test.hs, Test.o ) > > ==================== Tidy Core ==================== > Result size = 20 > > Test.test2 :: GHC.Types.Int > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 10 110}] > Test.test2 = GHC.Types.I# 42 > > Test.test1 > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> Data.Maybe.Maybe GHC.Types.Int > [GblId, > Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 40 0}] > Test.test1 = > Data.HashMap.Base.lookup > @ GHC.Types.Int > @ GHC.Types.Int > GHC.Classes.$fEqInt > Data.Hashable.$fHashableInt > Test.test2 > > Test.test > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> GHC.Types.Int > [GblId, > Arity=1, > Str=DmdType L, > Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0] 40 0}] > Test.test = > \ (m_aPx > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> > case Test.test1 m_aPx of _ { > Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; > Data.Maybe.Just y_atN -> y_atN > } > }}} New description: If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.) Here's an example where it fails. First, the simple wrapper module: {{{ module Repro where import Data.Hashable import Data.HashMap.Strict as M infixl 9 ! (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b m ! x = case M.lookup x m of -- lookup is INLINABLE Just y -> y Nothing -> error "Repro.!" }}} and then the call site: {{{ module Test (test) where import Data.HashMap.Strict as M import Repro test :: M.HashMap Int Int -> Int test m = m ! 42 }}} To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered- containers is: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing #if __GLASGOW_HASKELL__ >= 700 {-# INLINABLE lookup #-} #endif }}} If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that. The core for `Repro` and `Test` is: {{{ $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) ==================== Tidy Core ==================== Result size = 28 lvl_rNZ :: [GHC.Types.Char] [GblId] lvl_rNZ = GHC.CString.unpackCString# "Repro.!" Repro.!1 :: forall b_aBU. b_aBU [GblId, Str=DmdType b] Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ Repro.! :: forall a_atJ b_atK. (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK [GblId, Arity=4, Str=DmdType LLLL, Unf=Unf{Src=, TopLvl=True, Arity=4, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 70 0}] Repro.! = \ (@ a_aBT) (@ b_aBU) ($dEq_aBV :: GHC.Classes.Eq a_aBT) ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) (x_atM :: a_aBT) -> case Data.HashMap.Base.lookup @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL of _ { Data.Maybe.Nothing -> Repro.!1 @ b_aBU; Data.Maybe.Just y_atN -> y_atN } [2 of 2] Compiling Test ( Test.hs, Test.o ) ==================== Tidy Core ==================== Result size = 20 Test.test2 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [] 10 110}] Test.test2 = GHC.Types.I# 42 Test.test1 :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> Data.Maybe.Maybe GHC.Types.Int [GblId, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, Cheap=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Test.test1 = Data.HashMap.Base.lookup @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fEqInt Data.Hashable.$fHashableInt Test.test2 Test.test :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Str=DmdType L, Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 40 0}] Test.test = \ (m_aPx :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> case Test.test1 m_aPx of _ { Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; Data.Maybe.Just y_atN -> y_atN } }}} **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:21:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:21:46 -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.cee1806255a314b0914439f8681e7f03@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 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 danilo2: Old description: > If a function marked as `INLINABLE` is called indirectly through a simple > wrapper defined in a different module, specialization never happens (i.e. > none of the dictionaries are removed.) > > Here's an example where it fails. First, the simple wrapper module: > > {{{ > module Repro where > > import Data.Hashable > import Data.HashMap.Strict as M > > infixl 9 ! > (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b > m ! x = case M.lookup x m of -- lookup is INLINABLE > Just y -> y > Nothing -> error "Repro.!" > }}} > > and then the call site: > > {{{ > module Test (test) where > > import Data.HashMap.Strict as M > > import Repro > > test :: M.HashMap Int Int -> Int > test m = m ! 42 > }}} > > To compile the code you need to `cabal install unordered-containers`. The > relevant function (which is not getting specialized) from unordered- > containers is: > > {{{ > lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v > lookup k0 = go h0 k0 0 > where > h0 = hash k0 > go !_ !_ !_ Empty = Nothing > go h k _ (Leaf hx (L kx x)) > | h == hx && k == kx = Just x > | otherwise = Nothing > go h k s (BitmapIndexed b v) > | b .&. m == 0 = Nothing > | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex > b m)) > where m = mask h s > go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) > go h k _ (Collision hx v) > | h == hx = lookupInArray k v > | otherwise = Nothing > #if __GLASGOW_HASKELL__ >= 700 > {-# INLINABLE lookup #-} > #endif > }}} > > If `test` calls `lookup` directly, without using the `(!)` wrapper, > things get specialized. Manually marking `(!)` as `INLINABLE` works, but > users shouldn't have to do that. > > The core for `Repro` and `Test` is: > > {{{ > $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl > [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) > > ==================== Tidy Core ==================== > Result size = 28 > > lvl_rNZ :: [GHC.Types.Char] > [GblId] > lvl_rNZ = GHC.CString.unpackCString# "Repro.!" > > Repro.!1 :: forall b_aBU. b_aBU > [GblId, Str=DmdType b] > Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ > > Repro.! > :: forall a_atJ b_atK. > (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => > Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK > [GblId, > Arity=4, > Str=DmdType LLLL, > Unf=Unf{Src=, TopLvl=True, Arity=4, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0 0 0 0] 70 0}] > Repro.! = > \ (@ a_aBT) > (@ b_aBU) > ($dEq_aBV :: GHC.Classes.Eq a_aBT) > ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) > (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) > (x_atM :: a_aBT) -> > case Data.HashMap.Base.lookup > @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL > of _ { > Data.Maybe.Nothing -> Repro.!1 @ b_aBU; > Data.Maybe.Just y_atN -> y_atN > } > > > [2 of 2] Compiling Test ( Test.hs, Test.o ) > > ==================== Tidy Core ==================== > Result size = 20 > > Test.test2 :: GHC.Types.Int > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 10 110}] > Test.test2 = GHC.Types.I# 42 > > Test.test1 > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> Data.Maybe.Maybe GHC.Types.Int > [GblId, > Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 40 0}] > Test.test1 = > Data.HashMap.Base.lookup > @ GHC.Types.Int > @ GHC.Types.Int > GHC.Classes.$fEqInt > Data.Hashable.$fHashableInt > Test.test2 > > Test.test > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> GHC.Types.Int > [GblId, > Arity=1, > Str=DmdType L, > Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0] 40 0}] > Test.test = > \ (m_aPx > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> > case Test.test1 m_aPx of _ { > Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; > Data.Maybe.Just y_atN -> y_atN > } > }}} > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} New description: If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.) Here's an example where it fails. First, the simple wrapper module: {{{ module Repro where import Data.Hashable import Data.HashMap.Strict as M infixl 9 ! (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b m ! x = case M.lookup x m of -- lookup is INLINABLE Just y -> y Nothing -> error "Repro.!" }}} and then the call site: {{{ module Test (test) where import Data.HashMap.Strict as M import Repro test :: M.HashMap Int Int -> Int test m = m ! 42 }}} To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered- containers is: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing #if __GLASGOW_HASKELL__ >= 700 {-# INLINABLE lookup #-} #endif }}} If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that. The core for `Repro` and `Test` is: {{{ $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) ==================== Tidy Core ==================== Result size = 28 lvl_rNZ :: [GHC.Types.Char] [GblId] lvl_rNZ = GHC.CString.unpackCString# "Repro.!" Repro.!1 :: forall b_aBU. b_aBU [GblId, Str=DmdType b] Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ Repro.! :: forall a_atJ b_atK. (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK [GblId, Arity=4, Str=DmdType LLLL, Unf=Unf{Src=, TopLvl=True, Arity=4, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 70 0}] Repro.! = \ (@ a_aBT) (@ b_aBU) ($dEq_aBV :: GHC.Classes.Eq a_aBT) ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) (x_atM :: a_aBT) -> case Data.HashMap.Base.lookup @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL of _ { Data.Maybe.Nothing -> Repro.!1 @ b_aBU; Data.Maybe.Just y_atN -> y_atN } [2 of 2] Compiling Test ( Test.hs, Test.o ) ==================== Tidy Core ==================== Result size = 20 Test.test2 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [] 10 110}] Test.test2 = GHC.Types.I# 42 Test.test1 :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> Data.Maybe.Maybe GHC.Types.Int [GblId, Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False, ConLike=False, Cheap=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Test.test1 = Data.HashMap.Base.lookup @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fEqInt Data.Hashable.$fHashableInt Test.test2 Test.test :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Str=DmdType L, Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 40 0}] Test.test = \ (m_aPx :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> case Test.test1 m_aPx of _ { Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; Data.Maybe.Just y_atN -> y_atN } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:22:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:22:53 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.b9aea2cc295d7e53cb6d50b6bf01d280@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2: Old description: > Hello! > I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` > pragma works, but if I understand correctly, then there is a bug in GHC. > Lets consider this simple code: > > module `A`: > > {{{ > > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleInstances #-} > > module A where > > import Prelude > import GHC.TypeLits > > -- TF utils > > type family (a :: Nat) :== (b :: Nat) where > a :== a = 'True > a :== b = 'False > > type family If cond (a :: Nat) (b :: Nat) where > If 'True a b = a > If 'False a b = b > > -- Heavy TF computations > > type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 > HeavyTF n i = If > (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 > > type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 > HeavyTF' n = HeavyTF' (n - > 1) > > -- Params for tests (bigger numbers = longer compile times) > > type family NatOf a :: Nat > type instance NatOf Int = 12000 > type instance NatOf String = 12000 > > -- Type class to check GHC behavior > class PerfC1 a where perfc1 :: a -> String > instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" > ; {-# INLINABLE perfc1 #-} > > class CheckOk (n :: Nat) > instance CheckOk 0 -- where > > main_cache :: IO () > main_cache = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > > perfc1_Int :: Int -> String > perfc1_Int = perfc1 > > perfc1_String :: String -> String > perfc1_String = perfc1 > > {-# SPECIALIZE perfc1 :: Int -> String #-} > {-# SPECIALIZE perfc1 :: String -> String #-} > > ----- > > perfc1' :: PerfC1 a => a -> String > perfc1' = perfc1 > {-# INLINABLE perfc1' #-} > > {-# SPECIALIZE perfc1' :: Int -> String #-} > {-# SPECIALIZE perfc1' :: String -> String #-} > > }}} > > module `Test1`: > > {{{ > import A > > main = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > }}} > > module `Test2`: > > {{{ > import A > > main = do > print $ perfc1' (1 :: Int) > print $ perfc1' ("a" :: String) > }}} > > module `Test3`: > > {{{ > import A > > main = do > print $ perfc1_Int (1 :: Int) > print $ perfc1_String ("a" :: String) > }}} > > Compile with: > `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` > `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 > Test.hs` > > (I've used `-fenable-rewrite-rules` explicitly just to be sure it is > enabled. We can omit it because `-O2` enables it) > > If module `A` was already compiled the compilation times for `ghc 7.10.3` > were as follow: > - `Test1`: ~ 16s > - `Test2`: ~ 16s > - `Test3`: almost instant > > And for `ghc 8.0-rc1` were as follow: > - `Test1`: ~ 28s > - `Test2`: ~ 28s > - `Test3`: almost instant > > Here are 2 bugs to note: > > 1) the compilation times are much longer with new GHC > > 2) the specialize pragmas do not work New description: Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 -- where main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` (I've used `-fenable-rewrite-rules` explicitly just to be sure it is enabled. We can omit it because `-O2` enables it) If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever eating GBs of RAM: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:25:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:25:27 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.7b2c1570f5688ca9cac141b82ca90a24@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2: Old description: > Hello! > I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` > pragma works, but if I understand correctly, then there is a bug in GHC. > Lets consider this simple code: > > module `A`: > > {{{ > > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleInstances #-} > > module A where > > import Prelude > import GHC.TypeLits > > -- TF utils > > type family (a :: Nat) :== (b :: Nat) where > a :== a = 'True > a :== b = 'False > > type family If cond (a :: Nat) (b :: Nat) where > If 'True a b = a > If 'False a b = b > > -- Heavy TF computations > > type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 > HeavyTF n i = If > (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 > > type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 > HeavyTF' n = HeavyTF' (n - > 1) > > -- Params for tests (bigger numbers = longer compile times) > > type family NatOf a :: Nat > type instance NatOf Int = 12000 > type instance NatOf String = 12000 > > -- Type class to check GHC behavior > class PerfC1 a where perfc1 :: a -> String > instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" > ; {-# INLINABLE perfc1 #-} > > class CheckOk (n :: Nat) > instance CheckOk 0 -- where > > main_cache :: IO () > main_cache = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > > perfc1_Int :: Int -> String > perfc1_Int = perfc1 > > perfc1_String :: String -> String > perfc1_String = perfc1 > > {-# SPECIALIZE perfc1 :: Int -> String #-} > {-# SPECIALIZE perfc1 :: String -> String #-} > > ----- > > perfc1' :: PerfC1 a => a -> String > perfc1' = perfc1 > {-# INLINABLE perfc1' #-} > > {-# SPECIALIZE perfc1' :: Int -> String #-} > {-# SPECIALIZE perfc1' :: String -> String #-} > > }}} > > module `Test1`: > > {{{ > import A > > main = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > }}} > > module `Test2`: > > {{{ > import A > > main = do > print $ perfc1' (1 :: Int) > print $ perfc1' ("a" :: String) > }}} > > module `Test3`: > > {{{ > import A > > main = do > print $ perfc1_Int (1 :: Int) > print $ perfc1_String ("a" :: String) > }}} > > Compile with: > `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` > `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 > Test.hs` > > (I've used `-fenable-rewrite-rules` explicitly just to be sure it is > enabled. We can omit it because `-O2` enables it) > > If module `A` was already compiled the compilation times for `ghc 7.10.3` > were as follow: > - `Test1`: ~ 16s > - `Test2`: ~ 16s > - `Test3`: almost instant > > And for `ghc 8.0-rc1` were as follow: > - `Test1`: ~ 28s > - `Test2`: ~ 28s > - `Test3`: almost instant > > Here are 2 bugs to note: > > 1) the compilation times are much longer with new GHC > > 2) the specialize pragmas do not work > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever eating GBs of RAM: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} New description: Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations -- it is just nested loop - the first Nat is the number of loops and the second is the size of loop -- As a result we ALWAYS get 0. type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` (I've used `-fenable-rewrite-rules` explicitly just to be sure it is enabled. We can omit it because `-O2` enables it) If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever eating GBs of RAM: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:26:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:26:55 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.784c21379b29e0ae61eb4bea7872ac83@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2: Old description: > Hello! > I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` > pragma works, but if I understand correctly, then there is a bug in GHC. > Lets consider this simple code: > > module `A`: > > {{{ > > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleInstances #-} > > module A where > > import Prelude > import GHC.TypeLits > > -- TF utils > > type family (a :: Nat) :== (b :: Nat) where > a :== a = 'True > a :== b = 'False > > type family If cond (a :: Nat) (b :: Nat) where > If 'True a b = a > If 'False a b = b > > -- Heavy TF computations > -- it is just nested loop - the first Nat is the number of loops and the > second is the size of loop > -- As a result we ALWAYS get 0. > > type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 > HeavyTF n i = If > (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 > > type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 > HeavyTF' n = HeavyTF' (n - > 1) > > -- Params for tests (bigger numbers = longer compile times) > > type family NatOf a :: Nat > type instance NatOf Int = 12000 > type instance NatOf String = 12000 > > -- Type class to check GHC behavior > class PerfC1 a where perfc1 :: a -> String > instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" > ; {-# INLINABLE perfc1 #-} > > class CheckOk (n :: Nat) > instance CheckOk 0 > > main_cache :: IO () > main_cache = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > > perfc1_Int :: Int -> String > perfc1_Int = perfc1 > > perfc1_String :: String -> String > perfc1_String = perfc1 > > {-# SPECIALIZE perfc1 :: Int -> String #-} > {-# SPECIALIZE perfc1 :: String -> String #-} > > ----- > > perfc1' :: PerfC1 a => a -> String > perfc1' = perfc1 > {-# INLINABLE perfc1' #-} > > {-# SPECIALIZE perfc1' :: Int -> String #-} > {-# SPECIALIZE perfc1' :: String -> String #-} > > }}} > > module `Test1`: > > {{{ > import A > > main = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > }}} > > module `Test2`: > > {{{ > import A > > main = do > print $ perfc1' (1 :: Int) > print $ perfc1' ("a" :: String) > }}} > > module `Test3`: > > {{{ > import A > > main = do > print $ perfc1_Int (1 :: Int) > print $ perfc1_String ("a" :: String) > }}} > > Compile with: > `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` > `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 > Test.hs` > > (I've used `-fenable-rewrite-rules` explicitly just to be sure it is > enabled. We can omit it because `-O2` enables it) > > If module `A` was already compiled the compilation times for `ghc 7.10.3` > were as follow: > - `Test1`: ~ 16s > - `Test2`: ~ 16s > - `Test3`: almost instant > > And for `ghc 8.0-rc1` were as follow: > - `Test1`: ~ 28s > - `Test2`: ~ 28s > - `Test3`: almost instant > > Here are 2 bugs to note: > > 1) the compilation times are much longer with new GHC > > 2) the specialize pragmas do not work > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever eating GBs of RAM: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} New description: Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations -- it is just nested loop - the first Nat is the size of loop while the second one is the number of loops -- As a result we ALWAYS get 0. type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` (I've used `-fenable-rewrite-rules` explicitly just to be sure it is enabled. We can omit it because `-O2` enables it) If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever eating GBs of RAM: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:57:42 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.c9f9a2c78ee9c1712cde06a7b2c69318@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2: Old description: > Hello! > I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` > pragma works, but if I understand correctly, then there is a bug in GHC. > Lets consider this simple code: > > module `A`: > > {{{ > > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleInstances #-} > > module A where > > import Prelude > import GHC.TypeLits > > -- TF utils > > type family (a :: Nat) :== (b :: Nat) where > a :== a = 'True > a :== b = 'False > > type family If cond (a :: Nat) (b :: Nat) where > If 'True a b = a > If 'False a b = b > > -- Heavy TF computations > -- it is just nested loop - the first Nat is the size of loop while the > second one is the number of loops > -- As a result we ALWAYS get 0. > > type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 > HeavyTF n i = If > (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 > > type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 > HeavyTF' n = HeavyTF' (n - > 1) > > -- Params for tests (bigger numbers = longer compile times) > > type family NatOf a :: Nat > type instance NatOf Int = 12000 > type instance NatOf String = 12000 > > -- Type class to check GHC behavior > class PerfC1 a where perfc1 :: a -> String > instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" > ; {-# INLINABLE perfc1 #-} > > class CheckOk (n :: Nat) > instance CheckOk 0 > > main_cache :: IO () > main_cache = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > > perfc1_Int :: Int -> String > perfc1_Int = perfc1 > > perfc1_String :: String -> String > perfc1_String = perfc1 > > {-# SPECIALIZE perfc1 :: Int -> String #-} > {-# SPECIALIZE perfc1 :: String -> String #-} > > ----- > > perfc1' :: PerfC1 a => a -> String > perfc1' = perfc1 > {-# INLINABLE perfc1' #-} > > {-# SPECIALIZE perfc1' :: Int -> String #-} > {-# SPECIALIZE perfc1' :: String -> String #-} > > }}} > > module `Test1`: > > {{{ > import A > > main = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > }}} > > module `Test2`: > > {{{ > import A > > main = do > print $ perfc1' (1 :: Int) > print $ perfc1' ("a" :: String) > }}} > > module `Test3`: > > {{{ > import A > > main = do > print $ perfc1_Int (1 :: Int) > print $ perfc1_String ("a" :: String) > }}} > > Compile with: > `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` > `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 > Test.hs` > > (I've used `-fenable-rewrite-rules` explicitly just to be sure it is > enabled. We can omit it because `-O2` enables it) > > If module `A` was already compiled the compilation times for `ghc 7.10.3` > were as follow: > - `Test1`: ~ 16s > - `Test2`: ~ 16s > - `Test3`: almost instant > > And for `ghc 8.0-rc1` were as follow: > - `Test1`: ~ 28s > - `Test2`: ~ 28s > - `Test3`: almost instant > > Here are 2 bugs to note: > > 1) the compilation times are much longer with new GHC > > 2) the specialize pragmas do not work > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever eating GBs of RAM: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} New description: Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations -- it is just nested loop - the first Nat is the size of loop while the second one is the number of loops -- As a result we ALWAYS get 0. type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` (I've used `-fenable-rewrite-rules` explicitly just to be sure it is enabled. We can omit it because `-O2` enables it) If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever eating GBs of RAM: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} **EDIT 2** I would like to take the opportunity here to ask a related question ? I was trying to specidy the rewrite rules manually, but GHC rejects the following ones (It accepts one of them, but not both, somehow thinking that `perfcx` is monomorphic): {{{ {-# RULES "perfcx/Int" forall (a :: Int). perfcx (a :: Int) = perfc1_Int a "perfcx/String" forall (b :: String). perfcx (b :: String) = perfc1_String b #-} perfcx = perfc1 {-# NOINLINE perfcx #-} [...] }}} But If I'm dumping the rules generated by GHC (using `-ddump-rules`) I can see both of the rules generated, so there probably is a way to define them: {{{ "SPEC perfc1'" [ALWAYS] forall ($dPerfC1 :: PerfC1 Int). perfc1' @ Int $dPerfC1 = $sperfc3 "SPEC perfc1'" [ALWAYS] forall ($dPerfC1 :: PerfC1 String). perfc1' @ String $dPerfC1 = $sperfc1 "SPEC/A perfc1 @ Int" [ALWAYS] forall (tpl :: PerfC1 Int). perfc1 @ Int tpl = $sperfc3 "SPEC/A perfc1 @ String" [ALWAYS] forall (tpl :: PerfC1 String). perfc1 @ String tpl = $sperfc1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 03:59:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 03:59:55 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.e4af57565e1697d5bd8db73b180dac50@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 danilo2: Old description: > Hello! > I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` > pragma works, but if I understand correctly, then there is a bug in GHC. > Lets consider this simple code: > > module `A`: > > {{{ > > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleInstances #-} > > module A where > > import Prelude > import GHC.TypeLits > > -- TF utils > > type family (a :: Nat) :== (b :: Nat) where > a :== a = 'True > a :== b = 'False > > type family If cond (a :: Nat) (b :: Nat) where > If 'True a b = a > If 'False a b = b > > -- Heavy TF computations > -- it is just nested loop - the first Nat is the size of loop while the > second one is the number of loops > -- As a result we ALWAYS get 0. > > type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 > HeavyTF n i = If > (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 > > type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 > HeavyTF' n = HeavyTF' (n - > 1) > > -- Params for tests (bigger numbers = longer compile times) > > type family NatOf a :: Nat > type instance NatOf Int = 12000 > type instance NatOf String = 12000 > > -- Type class to check GHC behavior > class PerfC1 a where perfc1 :: a -> String > instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" > ; {-# INLINABLE perfc1 #-} > > class CheckOk (n :: Nat) > instance CheckOk 0 > > main_cache :: IO () > main_cache = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > > perfc1_Int :: Int -> String > perfc1_Int = perfc1 > > perfc1_String :: String -> String > perfc1_String = perfc1 > > {-# SPECIALIZE perfc1 :: Int -> String #-} > {-# SPECIALIZE perfc1 :: String -> String #-} > > ----- > > perfc1' :: PerfC1 a => a -> String > perfc1' = perfc1 > {-# INLINABLE perfc1' #-} > > {-# SPECIALIZE perfc1' :: Int -> String #-} > {-# SPECIALIZE perfc1' :: String -> String #-} > > }}} > > module `Test1`: > > {{{ > import A > > main = do > print $ perfc1 (1 :: Int) > print $ perfc1 ("a" :: String) > }}} > > module `Test2`: > > {{{ > import A > > main = do > print $ perfc1' (1 :: Int) > print $ perfc1' ("a" :: String) > }}} > > module `Test3`: > > {{{ > import A > > main = do > print $ perfc1_Int (1 :: Int) > print $ perfc1_String ("a" :: String) > }}} > > Compile with: > `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` > `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 > Test.hs` > > (I've used `-fenable-rewrite-rules` explicitly just to be sure it is > enabled. We can omit it because `-O2` enables it) > > If module `A` was already compiled the compilation times for `ghc 7.10.3` > were as follow: > - `Test1`: ~ 16s > - `Test2`: ~ 16s > - `Test3`: almost instant > > And for `ghc 8.0-rc1` were as follow: > - `Test1`: ~ 28s > - `Test2`: ~ 28s > - `Test3`: almost instant > > Here are 2 bugs to note: > > 1) the compilation times are much longer with new GHC > > 2) the specialize pragmas do not work > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever eating GBs of RAM: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} > > **EDIT 2** > I would like to take the opportunity here to ask a related question ? I > was trying to specidy the rewrite rules manually, but GHC rejects the > following ones (It accepts one of them, but not both, somehow thinking > that `perfcx` is monomorphic): > > {{{ > > {-# RULES > "perfcx/Int" forall (a :: Int). perfcx (a :: Int) = perfc1_Int > a > "perfcx/String" forall (b :: String). perfcx (b :: String) = > perfc1_String b > #-} > > perfcx = perfc1 > {-# NOINLINE perfcx #-} > > [...] > > }}} > > But If I'm dumping the rules generated by GHC (using `-ddump-rules`) I > can see both of the rules generated, so there probably is a way to define > them: > > {{{ > > "SPEC perfc1'" [ALWAYS] > forall ($dPerfC1 :: PerfC1 Int). perfc1' @ Int $dPerfC1 = $sperfc3 > "SPEC perfc1'" [ALWAYS] > forall ($dPerfC1 :: PerfC1 String). > perfc1' @ String $dPerfC1 > = $sperfc1 > "SPEC/A perfc1 @ Int" [ALWAYS] > forall (tpl :: PerfC1 Int). perfc1 @ Int tpl = $sperfc3 > "SPEC/A perfc1 @ String" [ALWAYS] > forall (tpl :: PerfC1 String). perfc1 @ String tpl = $sperfc1 > > }}} New description: Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations -- it is just nested loop - the first Nat is the size of loop while the second one is the number of loops -- As a result we ALWAYS get 0. type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test.hs` (I've used `-fenable-rewrite-rules` explicitly just to be sure it is enabled. We can omit it because `-O2` enables it) If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever eating GBs of RAM: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} **EDIT 2** I would like to take the opportunity here to ask a related question ? I was trying to specidy the rewrite rules manually, but GHC rejects the following ones (It accepts one of them, but not both, somehow thinking that `perfcx` is monomorphic). I know that the rules are fired when GHC uses CORE, so typeclasses are "just normal polymorphic objects" and "hidden inputs", but are we able to specify them somehow? {{{ {-# RULES "perfcx/Int" forall (a :: Int). perfcx (a :: Int) = perfc1_Int a "perfcx/String" forall (b :: String). perfcx (b :: String) = perfc1_String b #-} perfcx = perfc1 {-# NOINLINE perfcx #-} [...] }}} But If I'm dumping the rules generated by GHC (using `-ddump-rules`) I can see both of the rules generated, so there probably is a way to define them: {{{ "SPEC perfc1'" [ALWAYS] forall ($dPerfC1 :: PerfC1 Int). perfc1' @ Int $dPerfC1 = $sperfc3 "SPEC perfc1'" [ALWAYS] forall ($dPerfC1 :: PerfC1 String). perfc1' @ String $dPerfC1 = $sperfc1 "SPEC/A perfc1 @ Int" [ALWAYS] forall (tpl :: PerfC1 Int). perfc1 @ Int tpl = $sperfc3 "SPEC/A perfc1 @ String" [ALWAYS] forall (tpl :: PerfC1 String). perfc1 @ String tpl = $sperfc1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 12:22:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 12:22:31 -0000 Subject: [GHC] #11365: Worse performance with -O In-Reply-To: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> References: <056.62439bf31f82b27746ba8b4291c07e75@haskell.org> Message-ID: <071.04dae27367df16fa6a671a6c407df121@haskell.org> #11365: Worse performance with -O -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: duplicate | Keywords: optimization | performance concurrency Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #1168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #1168 Comment: > Ah yes! Just search for "replicateM" and you'll see a raft of tickets about this one problem! There is a link back to this ticket from #1168, so this example can still be found and used as a test if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 12:26:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 12:26:41 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.ce8424ca7de401724d0ef09afaaf8e49@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 12:27:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 12:27:11 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.a531af8b2da3f64fec5ef144cf1366af@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | patsyn/should_compile/T11367 Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => patsyn/should_compile/T11367 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 13:14:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 13:14:29 -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.254cc3abbc54b66c0e2e039df457af4e@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:3 goldfire]: > Post the output with `-fprint-explicit-kinds -fprint-explicit-foralls -ddump-tc -ddump-tc-trace -dverbose-core2core`. Thanks! The resulting file is too big to attach here (15 Mb). Here is how you can generate it yourself with `ghc-7.10.3`: {{{ git clone https://github.com/jbracker/polymonad-plugin cd polymonad-plugin/examples/core-error cabal sandbox init cabal install --dependencies-only # only takes a few seconds cabal build --ghc-options='-fprint-explicit-kinds -fprint-explicit-foralls -ddump-tc -ddump-tc-trace -dverbose-core2core' > dump 2>&1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 13:53:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 13:53:58 -0000 Subject: [GHC] #11384: Error says to fix incorrect return type In-Reply-To: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> References: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> Message-ID: <066.5deb815f26800ad508ab75a18689ca30@haskell.org> #11384: Error says to fix incorrect return type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: 8258 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Incorrect warning at compile-time * version: 8.1 => 7.6.3 * blockedby: => 8258 Comment: Good idea. #8258 would help with the first suggestion (enabling `GADTs`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 16:34:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 16:34:34 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs Message-ID: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- To reproduce, clone https://github.com/rrnewton/haskell-lockfree and switch to ghc-8.0 branch. Then run {{{cabal install atomic-primops/}}} (note the trailing slash, we don't want to install it from Hackage). It should fail with a message like this: {{{ ? haskell-lockfree git:(ghc-8.0) ? cabal install atomic-primops/ Warning: The package list for 'hackage.haskell.org' is 25.1 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Notice: installing into a sandbox located at /home/omer/haskell/haskell-lockfree/.cabal-sandbox Configuring primitive-0.6.1.0... Building primitive-0.6.1.0... Warning: /tmp/pkgConf-primitive-0.6.110252023621350490027.0: Unrecognized field abi on line 21 Installed primitive-0.6.1.0 Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Failed to install atomic-primops-0.8.0.2 Build log ( /home/omer/haskell/haskell-lockfree/.cabal-sandbox/logs /atomic-primops-0.8.0.2.log ): [1 of 1] Compiling Main ( atomic-primops/dist/dist-sandbox- ad71ba7e/setup/setup.hs, atomic-primops/dist/dist-sandbox- ad71ba7e/setup/Main.o ) Linking atomic-primops/dist/dist-sandbox-ad71ba7e/setup/setup ... Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Preprocessing library atomic-primops-0.8.0.2... [1 of 3] Compiling Data.Atomics.Internal ( Data/Atomics/Internal.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Internal.o ) Data/Atomics/Internal.hs:69:20: warning: Defined but not used: data constructor ?Ticket? [2 of 3] Compiling Data.Atomics.Counter ( Data/Atomics/Counter.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Counter.o ) [3 of 3] Compiling Data.Atomics ( Data/Atomics.hs, dist/dist-sandbox- ad71ba7e/build/Data/Atomics.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): applyTypeToArgs Expression: readMutVar# eta_s4sC st_s4sD Type: forall d_15 a_12. MutVar# d_15 a_12 -> State# d_15 -> (# State# d_15, a_12 #) Args: [eta_s4sC, st_s4sD] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: atomic-primops-0.8.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 16:40:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 16:40:56 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.97ecfe6f2be0ffa10518a6c8ee019d4a@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): So it seems like {{{readMutVar#}}} now has two extra arguments, I'm guessing this is related with levity args? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 17:06:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 17:06:38 -0000 Subject: [GHC] #11380: Compiling a 10.000 line file exhausts memory (was: `cabal repl` exhausts memory) In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.74b3d3c7e092c2907d98cd5acfca43cb@haskell.org> #11380: Compiling a 10.000 line file exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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 thomie): * failure: Compile-time crash => Compile-time performance bug Comment: Compiling (instead of interpreting) the generated Parser.hs with ghc-7.10.3 (wihout optimizations) doesn't complete either, when only 3GB of RAM is available (tested with `ulimit -v 3000000`). The problems seem to begin in the desugaring phase: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: ghc: out of memory (requested 2097152 bytes) }}} The generated parser is huge (10.000 lines). But it is about the same size as GHC's own parser, which GHC //is// able to compile with reasonable memory. I tried making the Parser smaller a bit, but didn't find any obvious rule that might be triggering the problem. Could you try with other version of GHC (say 7.8.4 and 8.0.1)? Is it a regression, or maybe already fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 17:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 17:20:11 -0000 Subject: [GHC] #11380: Compiling a 10.000 line file exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.9db58558e542fe15db6a998105a699e8@haskell.org> #11380: Compiling a 10.000 line file exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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 jstolarek): kennethb, what happens when you try to compile your parser with `-O0` option (ie. without optimizations)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 17:45:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 17:45:58 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.153970fa4bf848807261de299d026f11@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): Also reproduced with 8.1.20160116. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 18:16:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 18:16:27 -0000 Subject: [GHC] #11380: Compiling a 10.000 line file exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.2a7f2f796de2958d5f177e2a465e3ccf@haskell.org> #11380: Compiling a 10.000 line file exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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 thomie): `happy` has a `-a` flag: {{{ -a --array generate an array-based parser }}} Cabal calls `happy -agc` by default, but I was using just `happy` in comment:4. It seems to influence the results when trying to compile `Parser.hs` within 3GB RAM. || ghc-7.10.3 Parser.hs ||= happy =||= happy -a =|| || -O0 || not ok || ok || || -O1 || ok || ok || @jstolek: compiling the non-array based parser //without// optimizations fails. Very strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 18:57:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 18:57:29 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.ddcb389cc89c981600b41ae2db8f004c@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted ---------------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: arm Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by bgamari): I would say that this really isn't a GHC so much as it is a `pureMD5` issue. While it's pretty reasonable to request that GHC inline the `unsafeUseAsCString` form of `getNthWord`, the `cereal` version produces far too much code to be worth inlining. Despite this, the library forces GHC to inline in both cases, hence the explosion during simplification. I have opened a [[https://github.com/TomMD/pureMD5/pull/3|pull request]] fixing this upstream. I haven't yet looked at the `chatter` issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 19:03:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 19:03:16 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.a2f19f905956f8237da219160c55a726@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie): * priority: normal => highest * milestone: => 8.0.1 Comment: Regression. Reproducible with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 19:42:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 19:42:18 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.e295dcd27c80b6550ad9e58658b68105@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie): * priority: normal => highest * milestone: => 8.0.1 Comment: Regression from 7.10.3. Assert failure in `shortCutReduction` in `TcInteract.hs` with `devel2` build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 19:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 19:45:33 -0000 Subject: [GHC] #11402: Add Peano numbers In-Reply-To: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> References: <048.97945cf842499b9f8e43bb15e1770975@haskell.org> Message-ID: <063.e25a33830ed5012e2dcba6a2a19ff3ad@haskell.org> #11402: Add Peano numbers -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 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): Phab:D1760 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => wontfix Comment: * Proposal: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/25710 * Withdrawal: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/25728 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 19:59:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 19:59:36 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.ac62154f671fa4ef7dd9c43b9ba03288@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T11414 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:00:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:00:19 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced In-Reply-To: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> References: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> Message-ID: <065.38d8f74134f19ea9b2274ed5cd77a5a9@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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): Phab:D1772 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:01:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:01:02 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.2f884a8e29cc0354dcc9a034635cb1e7@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Old description: > {{{ > {-# LANGUAGE Strict #-} > main = print $ let x = undefined in True > }}} > > Using HEAD or GHC 8.0: > {{{ > $ ghc-8.0.0.20160109 Test.hs > [1 of 1] Compiling Main ( Test.hs, Test.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.0.20160109 for x86_64-unknown-linux): > StgCmmEnv: variable not found > $dIP_aDK > local binds for: > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Using a devel2 build: > {{{ > $ ./inplace/bin/ghc-stage2 Test.hs > [1 of 1] Compiling Main ( Test.hs, Test.o ) > WARNING: file compiler/simplCore/OccurAnal.hs, line 66 > Glomming in Main: [aDO :->] > WARNING: file compiler/coreSyn/CoreSubst.hs, line 278 > CoreSubst.lookupIdSubst simpleOptExpr $dIP_aDO > InScope [aDM :-> a_aDM] > WARNING: file compiler/simplCore/OccurAnal.hs, line 66 > Glomming in Main: [aDO :-> Once] > WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO > WARNING: file compiler/simplCore/OccurAnal.hs, line 66 > Glomming in Main: [aDO :-> Once] > WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.1.20160103 for x86_64-unknown-linux): > ASSERT failed! file compiler/stgSyn/CoreToStg.hs line 1025 > $dIP_aDO > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: {{{#!hs {-# LANGUAGE Strict #-} main = print $ let x = undefined in True }}} Using HEAD or GHC 8.0: {{{ $ ghc-8.0.0.20160109 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160109 for x86_64-unknown-linux): StgCmmEnv: variable not found $dIP_aDK local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Using a devel2 build: {{{ $ ./inplace/bin/ghc-stage2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :->] WARNING: file compiler/coreSyn/CoreSubst.hs, line 278 CoreSubst.lookupIdSubst simpleOptExpr $dIP_aDO InScope [aDM :-> a_aDM] WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :-> Once] WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO WARNING: file compiler/simplCore/OccurAnal.hs, line 66 Glomming in Main: [aDO :-> Once] WARNING: file compiler/simplCore/SimplEnv.hs, line 530 $dIP_aDO ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160103 for x86_64-unknown-linux): ASSERT failed! file compiler/stgSyn/CoreToStg.hs line 1025 $dIP_aDO 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 Sun Jan 17 20:07:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:07:00 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.b1cecd5fe4fb7ad3f9b1faf61e872177@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): syd: so what is your plan here? `ls` all files in current and parent directories, and then try to guess what the user meant? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:16:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:16:06 -0000 Subject: [GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure In-Reply-To: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> References: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> Message-ID: <060.c7dcdfe8f435caf034b8ff340b13dee5@haskell.org> #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 thomie): This is fixed in 7.10.3, 8.0.1 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:16:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:16:12 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.4b021b11877e64fe24251fb096d2620a@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:8 thomie]: > syd: so what is your plan here? `ls` all files in current and parent directories, and then try to guess what the user meant? That is a possibility. If that's the other option, compared to looking at the modules already compiled, we have to trade off looking into the directories for a possible false negative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:22:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:22:34 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.1636a9f324066de1a2e14c14395c865c@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): > compared to looking at the modules already compiled I don't understand. What are these "modules already compiled", in your example from the description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:25:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:25:58 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.be90d5511e46c63de41435c813c5020e@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:10 thomie]: > > compared to looking at the modules already compiled > > I don't understand. What are these "modules already compiled", in your example from the description. As said above: > Is there not some sort of cache of previously found modules that we can check? That won't be able to correct every typo but at least every typo for modules that have been compiled already. I didn't really get an answer then. If there is no such cache, then looking into the directories shouldn't be a problem because that would mean that GHC does that for every import. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 20:53:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 20:53:54 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.1e5daa07dfa16ea54160479132a30054@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It appears that the issue is introduced quite early in compilation as the output from desugaring fails core lint, {{{ *** Core Linted result of Desugar (after optimization): *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the expression: (\ (@ a_aKO) -> undefined) @ a_aKO @ 'Lifted @ a_aKO $dIP_aKQ $dIP_aKQ :: ?callStack::CallStack [LclId, Str=DmdType] is out of scope *** Offending Program *** main :: IO () [LclIdX, Str=DmdType] main = $ @ 'Lifted @ Bool @ (IO ()) (print @ Bool $fShowBool) (case \ (@ a_aKO) -> (\ (@ a_aKO) -> undefined) @ a_aKO @ 'Lifted @ a_aKO $dIP_aKQ of _ [Occ=Dead] { __DEFAULT -> True }) main :: IO () [LclIdX, Str=DmdType] main = runMainIO @ () main $trModule :: Module [LclIdX[ReflectionId], Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 21:14:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 21:14:24 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.d42c0c0e29fb46143464d6900416d502@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): Ok, let's back up. > Does that mean ghc hammers the file system with guesses for every import? Given the two files from the description, here's what happens when you run `ghc Aaa.hs`: * GHC asks the OS to open `./Aaa.hs`, and reads its contents * GHC figures out it needs module `BBb` * GHC "guesses" that `BBb` is either in `./BBb.hs` or in `./BBb.lhs` * GHC asks the OS to open those two files in order * Since neither file exists, an error message is shown (after also consulting the package database, but let's ignore that for the moment) So in total GHC tries to open 3 files: `Aaa.hs`, `BBb.hs` and `BBb.lhs`. It doesn't have to ask the OS for a list of all files in the directory. If you run `ghc Aaa.hs` again later, it will do the exact same thing. There is no cache. Even if there are another one million files in the current directory, GHC still has to only open those 3 files. It doesn't "hammer" the file system. > Is there not some sort of cache of previously found modules that we can check? Not in the above scenerio. But just to be clear: do you mean a cache that could be used between separate invocations of GHC, or within a single invocation of GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 21:17:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 21:17:02 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic In-Reply-To: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> References: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> Message-ID: <065.50f2ad5fb4b7f0ef41a0be09da035b7f@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): You don't even need `-XTypeInType`. I had this bite me earlier when I accidentally gave one too many type parameters to `K1`. {{{ class GEq1 t where gliftEq :: (a -> b -> Bool) -> t a -> t b -> Bool instance Eq c => GEq1 (K1 i c) where gliftEq _ (K1 c) (K1 d) = c == d }}} If you replace the instance with {{{ instance Eq c => GEq1 (K1 i c oops) where gliftEq _ (K1 c) (K1 d) = c == d }}} You get the same `fpProv falls into a hole` error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 21:18:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 21:18:26 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic In-Reply-To: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> References: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> Message-ID: <065.bc3b89ebbc3b2739f1fa8a094858a033@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * priority: normal => highest * cc: ekmett (added) * milestone: => 8.0.1 Comment: Upgrading to `highest` as this can affect normal users, not just those on the bleeding edge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 21:35:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 21:35:23 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.5203f753424116754ec9ff7f882f09c1@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I fixed this, submitting a patch in a minute. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 21:50:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 21:50:07 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.2be126bfd0110bbc04c95bbc38bde1c0@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:12 thomie]: > Ok, let's back up. > > > Does that mean ghc hammers the file system with guesses for every import? > > Given the two files from the description, here's what happens when you run `ghc Aaa.hs`: > * GHC asks the OS to open `./Aaa.hs`, and reads its contents > * GHC figures out it needs module `BBb` > * GHC "guesses" that `BBb` is either in `./BBb.hs` or in `./BBb.lhs` > * GHC asks the OS to open those two files in order > * Since neither file exists, an error message is shown (after also consulting the package database, but let's ignore that for the moment) > > So in total GHC tries to open 3 files: `Aaa.hs`, `BBb.hs` and `BBb.lhs`. It doesn't have to ask the OS for a list of all files in the directory. Does that mean GHC tries both of those (multiplied by each extra source directory specified) for every import of `Aaa`? That may be something that could be optimized for `ghc --make`. > If you run `ghc Aaa.hs` again later, it will do the exact same thing. There is no cache. Thank you for this clarification! > Even if there are another one million files in the current directory, GHC still has to only open those 3 files. It doesn't "hammer" the file system. > > > Is there not some sort of cache of previously found modules that we can check? > > Not in the above scenerio. But just to be clear: do you mean a cache that could be used between separate invocations of GHC, or within a single invocation of GHC? I keep forgetting that there is a big difference between `ghc` and `ghc --make`. I meant `ghc --make`, I think, so a cache that works across seperate invocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 21:55:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 21:55:23 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.b5fe665202023b2616637ee7ecb1be06@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 22:27:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 22:27:04 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.dc6cf5c5f38272983d096fc56cde25df@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D1791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 22:39:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 22:39:54 -0000 Subject: [GHC] #11223: Runtime linker performs eager loading of all object files (was: Dynamic linker on Windows is unable to link against libmingwex) In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.0df60ecd8b0615bd2475aaefe7cc713f@haskell.org> #11223: Runtime linker performs eager loading of all object files -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Windows => Unknown/Multiple Comment: The Runtime Linker is currently eagerly loading all object files on all platforms which do not use the system linker for `GHCi`. After talking with @rwbarton I have taken the approach of loading entire object files when a symbol is needed instead of doing the dependency tracking on a per symbol basis. This is a lot less fragile and a lot less complicated to implement. The changes come down to the following steps: 1) modify the linker to keep a list of required symbols. Required symbols are any symbols that are passed in from `.o` arguments to `GHCi`. 2) Change `ObjectCode`'s to be indexed but not initialized or resolved. This means we know where we would load the symbols, but haven't actually done so. 3) Mark any `ObjectCode` belonging to `.o` passed as argument as required `loadObject`. 4) During `Resolve` object calls, mark all `ObjectCode` containing the required symbols as `loadObject` 5) During `lookupSymbol` lookups, (which is called from `linkExpr` and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded `ObjectCode` then load the `ObjectCode` on demand and return the address of the symbol. Otherwise produce an unresolved symbols error as expected. This change affects all platforms and OSes which use the runtime linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 22:42:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 22:42:00 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.2cb2e8bcbe50172d585ac9592f2ff33a@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11422 | Differential Rev(s): Phab:D1787 Wiki Page: | ----------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"ae1c48c60abdfb134de7e247df851da101f0dd96/ghc" ae1c48c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae1c48c60abdfb134de7e247df851da101f0dd96" rts/posix: Fail with HEAPOVERFLOW when out of memory during mmap Test Plan: Validate Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1787 GHC Trac Issues: #11300 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 23:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 23:14:10 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.cb1e39de001d38bcd94d9c854d65c708@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d1ce1aa9beed4d3ecd3a0324ae4c98625fbe8d33/ghc" d1ce1aa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1ce1aa9beed4d3ecd3a0324ae4c98625fbe8d33" users-guide: Clean manpage build artifacts and fix usage of clean-target Test Plan: Build then clean Reviewers: austin, thomie Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1786 GHC Trac Issues: #11433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 23:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 23:14:10 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.f83151298177cbc86c9d5cc6077d8461@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f3a867e8aa0f6364aa3a152ca660c3c581412484/ghc" f3a867e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f3a867e8aa0f6364aa3a152ca660c3c581412484" Add testcase for #11414 Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1790 GHC Trac Issues: #11414 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 23:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 23:14:10 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.da9e4987c631dce0d2cc6adfbacbabb7@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"65b810bdda625f2e98069c2c56ec93e1c65667a6/ghc" 65b810b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="65b810bdda625f2e98069c2c56ec93e1c65667a6" Show TYPE 'Lifted/TYPE 'Unlifted as */# in Show TypeRep instance Kind equalities changed how `*`/`#` are represented internally, which means that showing a `TypeRep` that contains either of those kinds produces a rather gross-looking result, e.g., ``` > typeOf (Proxy :: Proxy 'Just) Proxy (TYPE 'Lifted -> Maybe (TYPE 'Lifted)) 'Just ``` We can at least special-case the `Show` instance for `TypeRep` so that it prints `*` to represent `TYPE 'Lifted` and `#` to represent `TYPE 'Unlifted`. Addresses one of the issues uncovered in #11334. Test Plan: ./validate Reviewers: simonpj, hvr, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1757 GHC Trac Issues: #11334 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 17 23:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jan 2016 23:14:10 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.e7ce565e3d500fee15576809fb143ebd@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Geraldus Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: completions | complete command operator Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9996 | Differential Rev(s): Phab:D1058 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b3eb8fad4c9d5aa293e197bfff7039d6fa112a54/ghc" b3eb8fa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b3eb8fad4c9d5aa293e197bfff7039d6fa112a54" Complete operators properly Fix operator completions: list of suitable completions only rather than everything from imported modules. Signed-off-by: Arthur Fayzrakhmanov (????? ????????????) ghc: fix operator completions Reviewers: austin, hvr, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1058 GHC Trac Issues: #10576 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 01:10:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 01:10:19 -0000 Subject: [GHC] #11446: Turn on SplitSections by default In-Reply-To: <045.7426d2a59085b256569e4a61a0c994e2@haskell.org> References: <045.7426d2a59085b256569e4a61a0c994e2@haskell.org> Message-ID: <060.b5b04f379af5b8425e34662219baf139@haskell.org> #11446: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 01:10:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 01:10:26 -0000 Subject: [GHC] #11447: Turn on SplitSections by default In-Reply-To: <045.fdb479cd02fc917f227e04a03b3024cb@haskell.org> References: <045.fdb479cd02fc917f227e04a03b3024cb@haskell.org> Message-ID: <060.bb143ecc60902e3b510901b8d9c0b493@haskell.org> #11447: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 01:16:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 01:16:07 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.db66746cd35744ae637630a118934739@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > This is a general tracking bug for what is blocking us from turning on > `SplitSections` by default, implemented in #8405. Fixing this, and > mandating use of the gold linker, will help solve #11285 (split objects > make linking slow), and will make ghc-split unnecessary, mooting #9832. > > I encountered some misinformation while talking to people about this > feature, regarding whether or not this feature only supported by Apple- > style linkers (i.e. on Mac OS X)? On IRC I heard a claim made that > `--split-sections` was only supported by Mac OS X. However, olsner > pointed out that `-split-sections` on GHC was OUR reimplementation of the > feature, and likely does not work on Mac OS X. > https://github.com/snowleopard/shaking-up- > ghc/issues/153#issuecomment-171078800 A later comment mentioned that > > So, can we turn on this feature by default? Does it subsume split-objs? > Does it work on all the tier-1 platforms? It would be nice if bgamari, > olsner and co could weigh in here. Thanks! New description: This is a general tracking bug for what is blocking us from turning on `SplitSections` by default, implemented in #8405. Fixing this, and mandating use of the gold linker, will help solve #11285 (split objects make linking slow), and will make ghc-split unnecessary, mooting #9832. I encountered some misinformation while talking to people about this feature, regarding whether or not this feature only supported by Apple- style linkers (i.e. on Mac OS X)? On IRC I heard a claim made that `--split-sections` was only supported by Mac OS X. However, olsner pointed out that `-split-sections` on GHC was OUR reimplementation of the feature, and likely does not work on Mac OS X. https://github.com/snowleopard /shaking-up-ghc/issues/153#issuecomment-171078800 A later comment mentioned that So, can we turn on this feature by default? Does it subsume split-objs? Does it work on all the tier-1 platforms? It would be nice if bgamari, olsner and co could weigh in here. Thanks! Also, there are two different ways we can do this. One is we can turn it on by default in the GHC build system, so all the base libraries and GHC are built with it (but when you invoke ghc, it does NOT have split sections); the other is to have GHC always run split sections, so user code also compiles with it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 01:22:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 01:22:56 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.ab55307f0d9a9fc9b9d02889baa1cea5@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): If the `.hs` file exists, GHC doesn't check for the `.lhs` file. I didn't make that clear. There is no difference between `ghc` and `ghc --make`: `--make` is the default mode. There is a difference between `-c` and `--make`. It would help if you described how you would like this caching mechanism to work, and how it would help with suggesting the correct spelling when a module is not found. Use the example from the description, or a different example if that makes things more clear. Don't worry too much about how GHC currently works; we can get back to that afterwards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 01:40:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 01:40:51 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.542a8745faa13ed583f537286d22591a@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:14 thomie]: > If the `.hs` file exists, GHC doesn't check for the `.lhs` file. I didn't make that clear. I assumed as much. I was just stating the worst-case. > > There is no difference between `ghc` and `ghc --make`: `--make` is the default mode. There is a difference between `-c` and `--make`. Okay. Thanks for clarrifying. > > It would help if you described how you would like this caching mechanism to work, and how it would help with suggesting the correct spelling when a module is not found. Use the example from the description, or a different example if that makes things more clear. Don't worry too much about how GHC currently works; we can get back to that afterwards. The caching system for module locations could work like this: Before compiling anything, ghc could scan the directory to find all the Haskell modules that are there and build a `Map ModuleName FilePath` (pseudocode). This assumes that there is not much in the directories other than the code you're trying to compile. It also assumes that you're not moving around modules during compilation. Both relatively valid assumptions. Applied to the example above: `ghc --make Aaa.hs` first looks through the directory and finds `Aaa` in file `Aaa.hs` and `Bbb` in file `Bbb.hs`. It then gives this information to any subsequent compilation procedures. Next, when going through `Aaa`, `ghc` figures out it needs to compile `Bbb` so it looks in the map to find the filepath where it's stored. (No more lookups in the filesystem at this point.) When `ghc` encounters `import BBb` (the spelling error) it looks in the map and notices that it cannot find `BBb`. It then goes through all the keys of the map and calculates the hamming distance/insert distance/some other metric between between the key and `BBb`. It notices that `Bbb` and `BBb` are similar and outputs the following helpful error message. {{{ Aaa.hs:3:1: Could not find module BBb. Perhaps you meant Bbb instead of BBb at line 3 of module Aaa (Aaa.hs) }}} Perhaps it could even locate the spelling mistake: {{{ Actual BBb Expected Bbb Diff _b_ }}} If anything is still unclear about this idea. Please don't hesitate to ask. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 03:19:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 03:19:17 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.17894710f8a665152e71b3d44c62ecf7@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): The gold linker only supports ELF, so it can't be used on OS X and Windows. GNU ld didn't support `--gc-sections` for PE/COFF [https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=0f088b2a9417b1d4ed597849ffa671eba25f5051 until recently], and this feature [https://ghc.haskell.org/trac/ghc/ticket/8405#comment:20 still appears to be buggy] according to olsner. So we'll need to fix those bugs in ld to make `-split-sections` work on Windows. According to the links you provided, OS X ld doesn't support `--gc- sections` at all, but maybe the `-dead_strip` option could be used. So on ELF platforms `-split-sections` should be ready to replace `-split- objs`; further testing and investigation is necessary on Windows and OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 08:55:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 08:55:07 -0000 Subject: [GHC] #11448: New --frontend mode is only partially documented Message-ID: <045.498508dda538a30f2c57476495771712@haskell.org> #11448: New --frontend mode is only partially documented -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 main documentation is here: * http://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html #frontend-plugins But it is missing from these pages: * http://downloads.haskell.org/~ghc/master/users-guide/using.html#modes * http://downloads.haskell.org/~ghc/master/users-guide/flags.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:29:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:29:22 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.d12cb060d7f14029285203a5e5da71a9@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): * Would ghc scan subdirectories as well (recursively?), when creating the map? * Would ghc persist this map to disk? (so it could be used on the next `ghc --make` run) * You mentioned a trade-off before. What would the other side of the trade-off look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:40:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:40:24 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations Message-ID: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- GHC doesn't treat `_` consistently in type declarations {{{ -- Example A data T _ = MkT -- Not allowed -- Example B class C a where type T a -- Example C class C [_] where -- Not allowed type T [_] = Int -- Not allowed -- Example D data family D a data instance D [_] = MkD -- Allowed -- Example E type family F a type instance F [_] = Int -- Allowed }}} This seems inconsistent and annoying (see [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026114.html email thread]). Really, we should consistently treat `_` in a binding position simply as ''a binder that binds nothing'', just like at the term level. But in Haskell 98 `_` is a reserved identifier, so these programs are illegal. We use `PartialTypeSignatures` to allow `_` in occurrence positions in types. Should the same flag enable `_` in binding positions? It would seem a little odd to require `PartialTypeSignatures` for (A) and (C). Any suggestions? A couple of wrinkles. First, since `_` binds nothing, it certainly doesn't bind occurrences of `_`. Thus for example, with `PartialTypeSignatures` {{{ instance C [_] where op = .... (let f :: _ -> _ f = e in ...) ... }}} The occurrences of `_` in `op`'s RHS are ''not'' bound by the `_` in the `instance` header. (The would be if all three were `a`, say.) Rather the occurrences of `_` are holes in the type signature and should be separately reported as such. Second, the implementation would be tricky in one spot: {{{ class C a where type T a instance C (Either _ _) where type T (Either _ _) = ... }}} We must check that the type family instance is at the same type as the class. Do we want to insist that it looks ''exactly'' the same, or would you be allowed to say this? {{{ instance C (Either _ _) where type T (Either a b) = a -> b }}} My instinct is to say "exactly the same" for now anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:40:29 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.0b67cc5ff35fa436681717cd01934f19@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:16 thomie]: > > * Would ghc scan subdirectories as well (recursively?), when creating the map? It would have to, I think. The idea is to have a comprehensive mapping of all the (non-package) modules that are available for imports. > * Would ghc persist this map to disk? (so it could be used on the next `ghc --make` run) No. Between runs of `ghc --make` the user may want to add new modules or move modules and that would invalidate this map. > * You mentioned a trade-off before. What would the other side of the trade-off look like? If you mean the 'trade-off' in comment 9, that is no longer applicable. What we are trading off here is: Loss: - Cost of scanning the entire directory. Gain: - Comprehensive mapping of modules that can be imported. - No file-system calls to find modules while resolving the imports. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:43:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:43:49 -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.6953e4921d1182fe97691064116d9d8d@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence type-checker | plugin 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: | -------------------------------------+------------------------------------- Comment (by jbracker): It's the same with ghc-7.10.2. The warning disappears when compiled with `-fno-opt-coercion`. Replying to [comment:2 thomie]: > `-fno-opt-coercion` makes the problem go away. Tested with ghc-7.10.3. > > The plugin doesn't compile with GHC 8 or HEAD, without significant changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:44:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:44:43 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance Message-ID: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 {{{ class C x where type T x instance C (Either a b) where type T (Either b a) = b -> a }}} This is bogus, because the equation for `T` has the parameters to `Either` reversed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:45:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:45:04 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.3da5539a7e0ec53ba991d8f28eb734e9@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > class C x where > type T x > > instance C (Either a b) where > type T (Either b a) = b -> a > }}} > This is bogus, because the equation for `T` has the parameters to > `Either` reversed. New description: Consider {{{ class C x where type T x instance C (Either a b) where type T (Either b a) = b -> a }}} This is bogus, because the equation for `T` has the parameters to `Either` reversed. But GHC 8.0 RC1 (and master) allow it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 09:54:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 09:54:01 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders Message-ID: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 compiling this with `-Wunused-matches`: {{{ class C a where op :: a -> a instance C (Maybe a) where op x = x }}} We get no warnings, even though `a` is patently unused. But suppose we add an associated type {{{ class C a where type T a op :: a -> a instance C (Maybe a) where type T (Maybe a) = Int -- Warning on this line op x = x }}} Now we get a warning for an unused binding for `a` on the `type instance`. Edward complained about this inconsistent behaviour in [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026114.html this email thread]. My thoughts: * Currently GHC does not warn about type variables bound in the instance head but unused in the `where` part. Fixing that might be a good idea, but would be a new feature. * However, given that we don't warn about them, we should definitely not warn about instance type variables being unused in an associated type. But we could warn about ones specific to the associated type itself. Eg {{{ class C2 a where type T2 a b instance C2 (Maybe a) where type T2 (Maybe a) x = Int -- Line XXX }}} Here, on line `XXX`, we might reasonably warn about the unused `x`, but not about the unused `a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:10:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:10:35 -0000 Subject: [GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure In-Reply-To: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> References: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> Message-ID: <060.7a8c9fa02a847aec5d8b19438026e2b5@haskell.org> #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Worth a regression test? It would probably duplicate an existing one, but still. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:22:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:22:30 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.cf75adca3e6dd0cb3cccc662253e1c97@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Lemming): I think that if a type variable is mentioned in an instance head this should count as usage. Then the according type patterns in associated types should be literally equal and should not get a warning. Thus I go with your second thought. Sure, this is somehow inconsistent with the value level, however, warning about unused type variables in this cases means I have to rewrite lots of code, even Haskell 98 code, to get rid of warnings and I guess, that `instance C (Maybe _)` is not even valid Haskell 98. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:23:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:23:50 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.e38fe6fa6b69e8b25da284f9a10ec48a@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a7b751db766bd456ace4f76a861e5e8b927d8f17/ghc" a7b751d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7b751db766bd456ace4f76a861e5e8b927d8f17" un-wire-in error, undefined, CallStack, and IP I missed a crucial step in the wiring-in process of `CallStack` in D861, the bit where you actually wire-in the Name... This led to a nasty bug where GHC thought `CallStack` was not wired-in and tried to fingerprint it, which failed because the defining module was not loaded. But we don't need `CallStack` to be wired-in anymore since `error` and `undefined` no longer need to be wired-in. So we just remove them all. Updates haddock submodule. Test Plan: `./validate` and `make slowtest TEST=tc198` Reviewers: simonpj, goldfire, austin, hvr, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1739 GHC Trac Issues: #11331 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:23:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:23:50 -0000 Subject: [GHC] #11434: Drop bzip2 in favor of xz In-Reply-To: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> References: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> Message-ID: <061.e26a00b4622504be569821b0cf9c1b45@haskell.org> #11434: Drop bzip2 in favor of xz -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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 Ben Gamari ): In [changeset:"2fd407cd28ea1c8fccb7a93d411d1cee690fa959/ghc" 2fd407c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fd407cd28ea1c8fccb7a93d411d1cee690fa959" validate: Use gz compression during bindist check Test Plan: validate, check that gz is used Reviewers: hvr, austin, thomie Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1788 GHC Trac Issues: #11434 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:39:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:39:08 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.3b500a9a6ed207ecd478bedd247a1591@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:39:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:39:23 -0000 Subject: [GHC] #11434: Drop bzip2 in favor of xz In-Reply-To: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> References: <046.103de6a94074ab2ce3a91b9d32794bc4@haskell.org> Message-ID: <061.59c7c033bdb6683f8d808be9a2b924f6@haskell.org> #11434: Drop bzip2 in favor of xz -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:43:17 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.00e559c3505e0ee6a11a90b7ea0eb7dd@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 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 Simon Peyton Jones ): In [changeset:"cb24e684759f3d181a104cde76f0f95da896a7ef/ghc" cb24e68/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb24e684759f3d181a104cde76f0f95da896a7ef" Fix typecheck of default associated type decls This bug was thrown up by Trac #11361, but I found that the problem was deeper: GHC was allowing class C a where type F (a :: k) :: * type F (x :: *) = x -- Not right! (Which is now indexed-types/should_compile/T11361a.) Anyway the fix is relatively simple; use tcMatchTys in tcDefaultAssocDecl. Merge to 8.0 branch. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:43:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:43:34 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.e9b42ebf7d88835e331cad33b3e70460@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): This feature could be called `-fhelpful-import-errors`. Do you think it should be enabled by default? We would have to ask others as well. Not only does scanning a directory take time, there is also a memory cost. A pretty bad scenario would be running ghc in $HOME. On my system: {{{ $ find ~ > all-files-in-home $ wc -l all-files-in-home 168014 all-files-in-home $ du -h all-files-in-home 14M all-files-in-home }}} You could exclude subdirectories that don't start with an uppercase letter from the scan. But Windows paths are case-insensitive, so it wouldn't help there. Or stop scanning after the first N=1000 or so files (do some measurements to see what's reasonable). How about this partial solution: * A lot of people use Cabal for library development * Cabal already asks you to specify all known modules in either `exposed- modules` or `other-modules` (I guess you could make typos here..) * Cabal already passes this list of modules to GHC * So GHC already knows the names of all modules that could possibly be imported (not quite, see https://github.com/haskell/cabal/issues/2982#issuecomment-169786310) * Use that list of modules to make spelling suggestions on import errors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:44:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:44:57 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.e2d4a48855689ab736ec4d28b9eab07d@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: merge Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11361, | T11361a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T11361, T11361a * status: new => merge Comment: Thanks for identifying this bug so clearly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:50:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:50:56 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.459b58267df431e71057f0e82276b080@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Actually this ticket #11is fixed by the following commit. I forgot to mention it in the list of fixes in the commit message. The important bit of the patch for #11379 is the new function `TcSMonad.mkShadowCt`, explained by `Note [Keep CDictCan shadows as CDictCan]`. Let's merge this. {{{ commit 9308c736d43b92bf8634babf565048e66e071bd8 Author: Simon Peyton Jones Date: Sat Jan 16 00:37:15 2016 +0000 Fix a number of subtle solver bugs As a result of some other unrelated changes I found that IndTypesPerf was failing, and opened Trac #11408. There's a test in indexed-types/should-compile/T11408. The bug was that a type like forall t. (MT (UL t) (UR t) ~ t) => UL t -> UR t -> Int is in fact unambiguous, but it's a bit subtle to prove that it is unambiguous. In investigating, Dimitrios and I found several subtle bugs in the constraint solver, fixed by this patch * canRewrite was missing a Derived/Derived case. This was lost by accident in Richard's big kind-equality patch. * Interact.interactTyVarEq would discard [D] a ~ ty if there was a [W] a ~ ty in the inert set. But that is wrong because the former can rewrite things that the latter cannot. Fix: a new function eqCanDischarge * In TcSMonad.addInertEq, the process was outright wrong for a Given/Wanted in the (GWModel) case. We were adding a new Derived without kicking out things that it could rewrite. Now the code is simpler (no special GWModel case), and works correctly. * The special case in kickOutRewritable for [W] fsk ~ ty, turns out not to be needed. (We emit a [D] fsk ~ ty which will do the job. I improved comments and documentation, esp in TcSMonad. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:55:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:55:35 -0000 Subject: [GHC] #11408: Delicate solve order In-Reply-To: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> References: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> Message-ID: <061.d95277a9f48a0b1202c1193485b2c805@haskell.org> #11408: Delicate solve order -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T11408 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:56:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:56:15 -0000 Subject: [GHC] #11430: ApiAnnotations: work SourceText in for all integer literals In-Reply-To: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> References: <044.7b08a4c14eb0af7388e7a58a702d14d7@haskell.org> Message-ID: <059.cee2dfccc8cc167f8b04c4f9133a5d97@haskell.org> #11430: ApiAnnotations: work SourceText in for all integer literals -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 953bbd31abcc1f328d1e70d5e84fceb402c07b42. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:57:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:57:17 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.d04a7814f577692f14d0e3bb6c1de1bb@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11422 | Differential Rev(s): Phab:D1787 Wiki Page: | ----------------------------------+---------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 30caafe829ce93a2e303b506cea21395b0a725eb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 10:57:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 10:57:25 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.414c3ef451a8724a3d237f4347bbbc61@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11422 | Differential Rev(s): Phab:D1787 Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:44:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:44:08 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.a42999a859a697922285ac402eff7325@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:46:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:46:26 -0000 Subject: [GHC] #11093: T9579 fails on OS X In-Reply-To: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> References: <046.f2b64e0980cbc13cb12e4a1a3513a03a@haskell.org> Message-ID: <061.a4ad9d62db686b65a27d5fb6297ee53f@haskell.org> #11093: T9579 fails on OS X ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.2 Resolution: worksforme | 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): * status: new => closed * resolution: => worksforme Comment: Oddly enough I can't reproduce this on our OS X test box. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:48:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:48:11 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.490f1b1ea1b77c8b1c420ed50e8ffd29@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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 Lemming): * cc: ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:49:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:49:34 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.03c49be38d9cb653d2b8d2374551d84e@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Lemming): * cc: ghc@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:51:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:51:16 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.dbbfb36e252ac1ddce6f9cbf2bf0de5c@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 bgamari): * priority: normal => high * milestone: => 8.0.1 Comment: We should really aim to get this fixed for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:54:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:54:40 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms In-Reply-To: <051.f6994676afcea2faaae7090f3210796a@haskell.org> References: <051.f6994676afcea2faaae7090f3210796a@haskell.org> Message-ID: <066.5eb97fd4d50ba6c4e66a199c62ebc93c@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e2c7b7ee976dcabf12002265ddbe58017b794cb8/ghc" e2c7b7ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2c7b7ee976dcabf12002265ddbe58017b794cb8" Implement scoped type variables in pattern synonyms This fixes Trac #11351. The implementation is pretty simple, happily. I took the opportunity to re-order the prov/req context in builder-ids, which was confusingly backwards. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:54:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:54:40 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.97fc297bcaff6a5a0b1415562a2054e8@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 Simon Peyton Jones ): In [changeset:"ec8a188a927a4db2e709541765e5ef545eae284c/ghc" ec8a188a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec8a188a927a4db2e709541765e5ef545eae284c" Refactoring on IdInfo and system derived names Some modest refactoring, triggered in part by Trac #11051 * Kill off PatSynId, ReflectionId in IdDetails They were barely used, and only for pretty-printing * Add helper function Id.mkExportedVanillaId, and use it * Polish up OccName.isDerivedOccName, as a predicate for definitions generated internally by GHC, which we might not want to show to the user. * Kill off unused OccName.mkDerivedTyConOcc * Shorten the derived OccNames for newtype and data instance axioms * A bit of related refactoring around newFamInstAxiomName }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:54:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:54:40 -0000 Subject: [GHC] #11427: superclasses aren't considered because context is no smaller than the instance head In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.3556b709593258e065ecb1f8c37aa48d@haskell.org> #11427: superclasses aren't considered because context is no smaller than the instance head -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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:"8e6a68d49a4f2ffd49990dc6b84135d93015d3f8/ghc" 8e6a68d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e6a68d49a4f2ffd49990dc6b84135d93015d3f8" Add Trac #11427 to Note [Recursive superclasses] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:54:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:54:40 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.a3fdda41490cff99ef2dd7671c4ecbb9@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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 Simon Peyton Jones ): In [changeset:"8e50301f7514751fc5c1fcc0e2847a49041ca2e7/ghc" 8e50301f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e50301f7514751fc5c1fcc0e2847a49041ca2e7" Test Trac #11379 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:56:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:56:48 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.cb54bab8b604488f58878175dba701ea@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => phab:D1792 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:57:02 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.4176af236415bf74492a4a4d0beec3f4@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` in b41586be7ba0659216c74ef8a58a0aa4d2cc2195. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:57:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:57:50 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.b6e9e8cf9a43bb4b289fe39df4d40bdb@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 simonpj): OK, Ben, is `isDerivedOccName` now enough to let you solve this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 11:58:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 11:58:44 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms In-Reply-To: <051.f6994676afcea2faaae7090f3210796a@haskell.org> References: <051.f6994676afcea2faaae7090f3210796a@haskell.org> Message-ID: <066.bb00385846707f278e1555372424699b@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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 simonpj): * status: new => merge Comment: I think it'd be safe to merge this. Still missing is a refactoring of the pattern-synonym documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:00:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:00:22 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.e129c0382e3c5bbcc8362862161f98f4@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as 9f466c8841c7ddda84951c9e3470540d25d0bfdb. The test will be merged shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:00:56 -0000 Subject: [GHC] #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms In-Reply-To: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> References: <051.4fc29d1d1432c0818764b100e3e42b0d@haskell.org> Message-ID: <066.b4bb32ede6e80cf0d8273ddeaf5e1499@haskell.org> #11367: [Regression] Only one clause allowed in (explicitly bidirectional) pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | patsyn/should_compile/T11367 Blocked By: | Blocking: Related Tickets: #393 #5791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` in e2c739772bfd12f1ad0bd900abbb34bc28de543e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:01:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:01:49 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced In-Reply-To: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> References: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> Message-ID: <065.f640cf21f9ce9830137fe700a5a02283@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | 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): Phab:D1772 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as 20f848b0e9020355340f3f0f2311d2f3d9aceb7c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:02:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:02:14 -0000 Subject: [GHC] #11422: outofmem RTS testcase fails on Windows In-Reply-To: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> References: <044.f4779da52215948aea0c20bd564ff35b@haskell.org> Message-ID: <059.9ec6810a9e831debefbfd0c6e5b9780c@haskell.org> #11422: outofmem RTS testcase fails on Windows ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: outpfmem Blocked By: | Blocking: Related Tickets: #11300 | Differential Rev(s): Phab:D1753 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: merge => closed Comment: This was merged to `ghc-8.0` as c95bb5e30ecf359bf12c3ce49c85fdfed6361dfb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:03:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:03:28 -0000 Subject: [GHC] #11408: Delicate solve order In-Reply-To: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> References: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> Message-ID: <061.475384555acc98fed95289a938052c2d@haskell.org> #11408: Delicate solve order -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T11408 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: This was merged to `ghc-8.0` as 9f466c8841c7ddda84951c9e3470540d25d0bfdb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:03:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:03:59 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.528c11b97ec74b07ff88461ff3010b68@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11361, | T11361a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:04:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:04:08 -0000 Subject: [GHC] #11408: Delicate solve order In-Reply-To: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> References: <046.0670f865badb31e8ec60d53a10d29017@haskell.org> Message-ID: <061.38591202e869650f7fb6ad212550e5b4@haskell.org> #11408: Delicate solve order -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T11408 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:19:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:19:03 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.195a8e23e2cc00d8321cdedd42281327@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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:D1782 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Both of these have been merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:24:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:24:31 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.d13911a5323de024d27bf51bc83a951b@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11361, | T11361a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This has been merged to `ghc-8.0` as 3b1dae2267241fa6a959e5d9785e20f712c11af0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:24:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:24:38 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.3c83fd400f10d257784fdce57013801d@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11361, | T11361a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:33:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:33:46 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.eee8333c97fb4a0958b6c362fa576c4f@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by thomie): * status: upstream => closed * resolution: => worksforme * milestone: 8.2.1 => 8.0.1 Comment: Replying to [comment:33 awson]: > GHC HEAD with LLVM 3.7 and current released binutils doesn't have this bug and works without any modifications. Ok, let's close this. There won't be another 7.10 release afaik. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:35:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:35:38 -0000 Subject: [GHC] #5063: unix package has untracked dependency on libbsd In-Reply-To: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> References: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> Message-ID: <060.66a2ae706ac964e02402ad65821b5c52@haskell.org> #5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: upstream Priority: low | Milestone: 8.2.1 Component: Core Libraries | Version: 7.0.3 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): * milestone: 8.0.1 => 8.2.1 Comment: What is the status of this? It seems like there have been no patches submitted upstream to resolve this. Punting to 8.2.1 unless informed otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:43:17 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.e2a605b1dafb8a5eff16ea64cb36e09f@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Bartosz [https://mail.haskell.org/pipermail/ghc- > devs/2016-January/010892.html reports] that substitution isn't working > properly for him. He cites this Note in `TyCoRep`: > {{{ > -- Note [Generating the in-scope set for a substitution] > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- If we want to substitute [a -> ty1, b -> ty2] I used to > -- think it was enough to generate an in-scope set that includes > -- fv(ty1,ty2). But that's not enough; we really should also take the > -- free vars of the type we are substituting into! Example: > -- (forall b. (a,b,x)) [a -> List b] > -- Then if we use the in-scope set {b}, there is a danger we will rename > -- the forall'd variable to 'x' by mistake, getting this: > -- (forall x. (List b, x, x)) > -- Urk! This means looking at all the calls to mkOpenTCvSubst.... > }}} > I think this is an outright bug that has been lurking for ages, and which > Bartosz has just managed to tickle. > > Things to do: > > * We should add an ASSERT to substTy (and similar functions): **when > calling `substTy subst ty` it should be the case that the in-scope set in > the substitution is a superset of** > * **The free vars of the range of the substitution** > * **The free vars of ty minus the domain of the substitution** > > That ASSERT could be added to the immediate callers of `subst_ty` in > `TyCoRep`. > > (Bartosz: if you add that you should find that it trips before the bug > you are actually getting.) > > * How to fix it properly? The places to look are: everywhere that uses > (transitively) one of the `mkOpenTCvSubst` or `zipOpenTCvSubst` > functions. > * Many calls to `mkOpenTCvSubst` produce a substitution that is only > applied to closed types; or at least to types whose only free variables > are the ones in the domain of the substitution. Example: the call to > `zipOpenTCvSubst` in `DataCon.dataConInstSig`. These ones will all > satisfy the ASSERT[[BR]][[BR]] > * In other cases, we already have the in-scope set in hand. Example: > in `CoreLint.lintTyApp` we find a call to `substTyWith`. But Lint > carries an in-scope set, so it would be easy to pass it to > `substTyWith`.[[BR]][[BR]] > * Finally there may be cases where we really have to take the free vars > of the type we are substituting into, and add them to the in-scope set. > > Doubtless all this applies to substituting in coercions too, and indeed > into expressions. New description: Bartosz [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010892.html reports] that substitution isn't working properly for him. He cites this Note in `TyCoRep`: {{{ -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x)) -- Urk! This means looking at all the calls to mkOpenTCvSubst.... }}} I think this is an outright bug that has been lurking for ages, and which Bartosz has just managed to tickle. Things to do: * We should add an ASSERT to substTy (and similar functions): **when calling `substTy subst ty` it should be the case that the in-scope set in the substitution is a superset of both** * **The free vars of the range of the substitution** * **The free vars of ty minus the domain of the substitution** That ASSERT could be added to the immediate callers of `subst_ty` in `TyCoRep`. (Bartosz: if you add that you should find that it trips before the bug you are actually getting.) * How to fix it properly? The places to look are: everywhere that uses (transitively) one of the `mkOpenTCvSubst` or `zipOpenTCvSubst` functions. * Many calls to `mkOpenTCvSubst` produce a substitution that is only applied to closed types; or at least to types whose only free variables are the ones in the domain of the substitution. Example: the call to `zipOpenTCvSubst` in `DataCon.dataConInstSig`. These ones will all satisfy the ASSERT[[BR]][[BR]] * In other cases, we already have the in-scope set in hand. Example: in `CoreLint.lintTyApp` we find a call to `substTyWith`. But Lint carries an in-scope set, so it would be easy to pass it to `substTyWith`.[[BR]][[BR]] * Finally there may be cases where we really have to take the free vars of the type we are substituting into, and add them to the in-scope set. Doubtless all this applies to substituting in coercions too, and indeed into expressions. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:44:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:44:44 -0000 Subject: [GHC] #11448: New --frontend mode is only partially documented In-Reply-To: <045.498508dda538a30f2c57476495771712@haskell.org> References: <045.498508dda538a30f2c57476495771712@haskell.org> Message-ID: <060.77324510fdab57467c210eed6d48dabf@haskell.org> #11448: New --frontend mode is only partially documented -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1793 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:47:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:47:01 -0000 Subject: [GHC] #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack In-Reply-To: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> References: <045.870effc6f9d420530058d0c3ce874e71@haskell.org> Message-ID: <060.19cbb50f3af17f4c593abf9d2826425f@haskell.org> #11331: panic! TEST=tc198: lookupVers2 GHC.Stack.Types CallStack -------------------------------------+------------------------------------- Reporter: thomie | Owner: gridaphobe Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` in b31aafb7064480055e067924e0ecfcf47e3082b0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:53:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:53:40 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.e6db092503b58fd7bfad069d51d601a7@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): So my previous attempt has failed, but, I added some inline comment in the Phabricator ticket to show how it's going wrong, so hopefully that'll help. I'll work on this later today but if someone has a fix please go ahead. (or I can do it if you just write the idea) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 12:55:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 12:55:35 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.2d6b27b8d6ae9f292b548448a36950be@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): I believe so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:00:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:00:40 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.a1b70673a4728384cd64c493aa4db3be@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I would love to see (A) accepted (perhaps with some language extension). I think (C) should be rejected. After all, the type variable ''is'' used there. It's used in the type family declaration, where `a` is not ''bound'' -- it is ''used''. Accordingly, {{{ class C a where type F a type F a = Int }}} should not emit any warnings. The only bound variable, `a`, is indeed used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:05:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:05:54 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.8297fc25e09f142eb5e8c449f03a2992@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Let's look more closely at {{{ instance C (Maybe a) where op x = x }}} Simon says that `a` is patently unused. I disagree: `a` is used in the instance head! The head of an instance is a type, and thus that `a` is a ''use'' site, not a ''binding'' site. The point of confusion is that we use usage sites to infer the implicit bindings. Contrast to a class declaration, where the type variables are indeed binding sites. Separately, I'm agreed with Simon's very last point about warning about `x` but not `a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:06:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:06:21 -0000 Subject: [GHC] #11351: Scoped type variables in pattern synonyms In-Reply-To: <051.f6994676afcea2faaae7090f3210796a@haskell.org> References: <051.f6994676afcea2faaae7090f3210796a@haskell.org> Message-ID: <066.e55c3c74a57e82bb188b410a31042541@haskell.org> #11351: Scoped type variables in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms 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 bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This has been merged to `ghc-8.0` as 8c10ee3cacdd4f88561751e96831435397aef4e9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:13:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:13:47 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.062a7546a993a5b7d599f51f8d2dcec7@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I see what you mean. After all, you could imagine that it is "really" {{{ instance forall a. C (Maybe a) where ... }}} BUT for `type instance` declarations we do allow {{{ type instance F (Maybe _) = Int }}} even though it's "really" {{{ type instance forall a. F (Maybe a) = Int }}} And here it really is persuasive to use `_`, in just the same way that we do in patterns in term-level function definitions. Why should the type patterns in a class instance declaration be treated differently than those in a type-family instance declaration? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:15:34 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.b0bbf2ba6c67b7e24c36eebe371e36fe@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted ---------------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: arm Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by bgamari): While I have no problem compiling `Conll`, the `Brown` module is indeed quite problematic, even on my laptop. This module produces an absolutely absurd amount of Core which appears to originate from the generic `Serialize` instances for the quite large `Tag` type. The attached `Test.hs` reproduces the blow-up. While the code size starts large-but-not insane, {{{ Result size of Desugar (after optimization) = {terms: 25,522, types: 972,788, coercions: 376,020} }}} Things quickly balloon during float-out, {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 254,872, types: 3,162,281, coercions: 634,615} }}} which the simplifier, through a great deal of effort, manages to reduce down to, {{{ Result size of CorePrep = {terms: 49,840, types: 1,752,631, coercions: 442,468} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:19:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:19:31 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.a7b45547883f5c186a3946cf12a94630@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Good point. They shouldn't be different. It's just that it seems so natural to say `instance C (Maybe a)`. But perhaps it shouldn't. In any case, this discovery subtly redefines the goal of the warning: 1. Warn when a type variable is bound explicitly but never used. 2. Warn when a type variable is bound implicitly but used in only one place. Refining the goal with point (2) clarifies why there should be no warning in `type instance Equals x x = True`. What do we think about `length :: [_] -> Int`? According to my goals above, that should be the correct type signature, as opposed to `length :: [a] -> Int` which should emit a warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:29:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:29:46 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.07e46064e32abb53c8ba89a913cc1892@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > What do we think about `length :: [_] -> Int`? No, this is not a use in a ''type pattern'' (as are all they cases discussed above). It's an occurrence, pure and simple. This is explicitly covered by `PartialTypeSignatures` and I don't want to change all of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:31:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:31:56 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity Message-ID: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The following module is accepted: {{{#!hs {-# LANGUAGE ExplicitForAll, TemplateHaskell #-} module Bug where impred :: forall a. a -> a impred = $$( [|| \x -> x ||] ) }}} But that requires an intermediate `TExp (forall a. a -> a)`. Will fix in ongoing work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:34:35 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.bc68530f9df9740ea71b55f0b57f99cf@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Phab:D1794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1794 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 13:37:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 13:37:24 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity In-Reply-To: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> References: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> Message-ID: <062.ec0d47a257c9589efc6089b19e145f3d@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Actually, my original example is OK; that's not impredicative, because the `a` can be bound outside the splice. But the following is accepted and really is impredicative: {{{#!hs {-# LANGUAGE RankNTypes, TemplateHaskell #-} module Bug where impred :: (forall a. a -> a) -> () impred = $$( [|| \_ -> () ||] ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 14:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 14:17:23 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.72472d32e9f5dc3f6e53dadb1b50a29b@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I think @goldfire might have solved it. I updated the patch and am currently waiting for validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 14:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 14:21:31 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.f058841c25fb01780d2e8bcdd728c7a7@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Phab:D1794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: simonpj => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 14:53:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 14:53:27 -0000 Subject: [GHC] #2374: MutableByteArray# is slower than Addr# In-Reply-To: <044.46877f1bb530048ac22aec20e1b9d3f2@haskell.org> References: <044.46877f1bb530048ac22aec20e1b9d3f2@haskell.org> Message-ID: <059.654784874ed2f53053284d29408d060f@haskell.org> #2374: MutableByteArray# is slower than Addr# -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler (NCG) | Version: 6.8.2 Resolution: | Keywords: performance | array Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, indeed there still seems to be a bit of a difference here ([[https://github.com/bgamari/T2374-benchmark|benchmark]]). {{{ benchmarking ptr time 949.1 ms (945.9 ms .. 953.2 ms) 1.000 R? (1.000 R? .. 1.000 R?) mean 954.2 ms (952.3 ms .. 955.7 ms) std dev 2.470 ms (0.0 s .. 2.710 ms) variance introduced by outliers: 19% (moderately inflated) benchmarking bytearr time 989.2 ms (979.9 ms .. 997.8 ms) 1.000 R? (1.000 R? .. 1.000 R?) mean 984.2 ms (981.2 ms .. 986.3 ms) std dev 3.125 ms (0.0 s .. 3.602 ms) variance introduced by outliers: 19% (moderately inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:10:36 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.dc2ab79448d1f27afc8f306c5f55e299@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): After `cabal install hashabler`, the problem is reproducible with this small program and a simple tick factor as high as `130`: Main.hs: {{{#!hs module Main where import Bloom main = do key <- undefined lookup_ key `seq` return () }}} Bloom.hs: {{{#!hs module Bloom where import Data.Hashabler {-# INLINE lookup_ #-} lookup_ :: SipKey -> Hash128 Int lookup_ key = siphash128 key 1 }}} {{{ $ ghc-7.10.3 Main.hs -O -fforce-recomp -fsimpl-tick-factor=130 # 135=ok ...Simplifier ticks exhausted... }}} Some observations: * Putting all code in a single module doesn't trigger the problem * This doesn't trigger the problem (I don't understand why not doing `key <- undefined` makes a difference..): {{{#!hs main = lookup_ undefined `seq` return () }}} * ghc-8.0.1 accepts the program with a tick factor as low as `85`. Did something change? I will attach a version of `Bloom.hs` with `hashabler` inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:11:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:11:35 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.0b3bcecfe831cc73ca384bb91c292243@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "Bloom.hs" added. Bloom with relevant parts of Hashabler inlined -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:21:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:21:02 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.cfb5181e43001e113e1f454a8afa907c@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Lemming): From a software engineering point of view a warning about `instance C (Maybe a) where` could be useful to alert the programmer that he might have forgotten to add superclass constraints on `a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:29:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:29:01 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.183334b2e4d9f7a2a7b7620abc90c300@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by nomeata): I just tried with 8.0.1-rc1, it is not fixed: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.0.0.20160111-3&stamp=1453130686 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:37:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:37:57 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.d21ca231d4a2dd0879717cc228c899d0@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): At the moment we can't reproduce this with 8.0.1 or HEAD, so we don't propose to fix it. tuplanolla: can you try with the release candidate for 8.0? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:39:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:39:55 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.b3f46c4235822c5a2cc75eefe08332e2@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 bgamari): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:39:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:39:58 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.7261699891c50b1f6cccda1e89c4bb8e@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): * owner: => bgamari Comment: Ben will try to reproduce on 8.0 or HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:40:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:40:45 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.a972477b45af80c17839dc620ab8e630@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Richard, this is marked as "highest" priority for 8.0.1 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:41:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:41:46 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.e6de839264aba52e17590f603a43390d@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: pattern | checker, 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 Phab:D1795 fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:43:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:43:16 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.5f392cd907f61642a5fe6d7340715664@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: goldfire => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:44:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:44:09 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.ba954e50e0900369674c352e2dc4c816@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | 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 simonpj): * owner: => goldfire Comment: Richard this one too is "highest". Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:45:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:45:13 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.717b4a24184f04f4a7aa6f86c29ce682@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: feature request | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:46:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:46:10 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.85bd2be3bb1c9d81b9d894c8b926239a@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:13 simonpj]: > > It would be super-helpful if someone could lay our the entire proposal. Still hoping for this? Since a spec precedes the implementation, and we want the implementation in 8.0.1, getting the spec is pretty urgent. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:47:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:47:26 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.fbcf1d5e60727342a42f56f714da5484@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): This is a regression relative to 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 15:48:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 15:48:39 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.6e017fb328107590e88784fd73fa116c@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: pattern | checker, 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 gkaracha): Replying to [comment:16 simonpj]: > Does Phab:D1795 fix this? Yes, it does. The current limits are: {{{ test('T11276', compile_timeout_multiplier(0.01), compile, ['-fwarn- incomplete-patterns -fwarn-overlapping-patterns +RTS -M1G -RTS']) }}} and it passes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 16:02:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 16:02:52 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.93aa77cd272304b4bfe0d3e9b5098345@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 simonpj): * owner: => bgamari Comment: This comes from the `inRange` case generated for `Ix`. We decided to use guards instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 16:27:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 16:27:10 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.c830d723f536c54e5e17e87ddadb76b2@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1797 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1797 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 16:29:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 16:29:34 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.de579a2134b5e8e37b81b21a8228bbb9@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 16:29:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 16:29:48 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.1f02a7334162b44d89ed5e53a0cbb8e7@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 16:37:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 16:37:09 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.9717e88bb4c97cd117cbf11ef09087f1@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:18 thomie]: > This feature could be called `-fhelpful-import-errors`. Do you think it should be enabled by default? That depends. See below. > We would have to ask others as well. > > Not only does scanning a directory take time, there is also a memory cost. A pretty bad scenario would be running ghc in $HOME. > > On my system: > {{{ > $ find ~ > all-files-in-home > $ wc -l all-files-in-home > 168014 all-files-in-home > $ du -h all-files-in-home > 14M all-files-in-home > }}} Yes. If we take this approach, the flag should definitely not be enabled by default. > Or stop scanning after the first N=1000 or so files (do some measurements to see what's reasonable). That is not feasable. We could miss out on modules we need. > How about this partial solution: > * A lot of people use Cabal for library development > * Cabal already asks you to specify all known modules in either `exposed-modules` or `other-modules` (I guess you could make typos here..) > * Cabal already passes this list of modules to GHC > * So GHC already knows the names of all modules that could possibly be imported (not quite, see https://github.com/haskell/cabal/issues/2982#issuecomment-169786310) > * Use that list of modules to make spelling suggestions on import errors If we take this approach, then I think the flag should be enabled by default. However: I, for example, use makefiles during development instead of cabal because it allows for a faster code/compile/fix type errors cycle. This solution would therefore not help me at all. I prefer the situation in which this is a non-default flag and cabal is not required for it to function. Feedback welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 17:21:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 17:21:15 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.d21d275d61613a29245d4e665373edbd@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): > I, for example, use makefiles during development instead of cabal because it allows for a faster code/compile/fix type errors cycle. Just curious: wouldn't `cabal repl` be faster? Or adding `ghc-options: -O0` to your `.cabal` file? If you want to proceed with the scanning the filesystem plan, I think it is best create a small wiki page, with a specification. See https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures. Basically copy what you wrote in comment:15 + clarifications from later comments. That way it is easier to digest for others, so they don't have to read through all these comments. Paste a link here, and send it to glasgow-haskell-users at haskell.org, requesting feedback. Hammering the file system might be frowned upon by some, so make sure you explain the flag (name to be decided by you) is off by default. In case you don't get any reactions, go to #ghc on the freenode irc channel, and ask bgamari (ghc maintainer) if he thinks it is ok to implement this. Then do it and submit a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 17:31:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 17:31:01 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.7fac5677aad4f7ef638af5685c585760@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 diatchki): I don't think that a direct "substitution" lemma makes sense in this context---remember that `F a` may not refer to a type at all, so we can't just put it in a place where a type is expected. So, if we had some type-expression `t`, and wanted to substitute `F a` for some variable `b`, we wouldn't do a direct substitution, but rather, we'd emit a new constraint: `F a ~ b`. Basically, the idea is that type functions are not really first class types, but may "introduce" types via constraints like: `F a ~ b`. So, if I write a type like `Maybe (F a)`, what I really mean is `(F a ~ b) => Maybe b`. Of course, if we can prove that `F a` is always defined we may "short-cut" the constraint part and just treat it as an ordinary type, but that's optional. This is basically the same idea is the "functional notation for functional dependencies" (section 3 of "Language and Program Design for Functional Dependencies"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 17:31:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 17:31:11 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.f5ef48facdf31820bdee2e32739588ad@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 18:30:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 18:30:07 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.9cf10fa75c527182b71c6931c19e12c4@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Sounds good to me. Note that `-hide-all-packages` is mentioned in the documentation for `MIN_VERSION_pkgname` and `VERSION_pkgname` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 18:30:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 18:30:08 -0000 Subject: [GHC] #11424: "Occurs check" not considered when reducing closed type families In-Reply-To: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> References: <047.97be24999398e6ba9d88fccbb4c0d682@haskell.org> Message-ID: <062.53fbcc4fbe7fd63ea0b12599b6a3d30c@haskell.org> #11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 goldfire): Yes. I think we're vigorously agreeing. Except that this is quite far from the way GHC works at the moment, and it's not a small change to make. I do think it's the right answer, in the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 19:13:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 19:13:21 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.9f0a61d967fbc345b4b2984b0ad7cc61@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by thomie): rassilon: you seem to know stuff. How to fix dynamic linking on Windows? Some more problems here: #4824 #5620 #7665 #8228. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 19:21:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 19:21:49 -0000 Subject: [GHC] #11453: Kinds in type synonym/data declarations can unexpectedly unify Message-ID: <050.b6d1aeccf29fe9a1ce1e81a78207e37f@haskell.org> #11453: Kinds in type synonym/data declarations can unexpectedly unify -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying out ideas to fix [https://github.com/ekmett/lens/issues/626 this lens issue], I noticed a couple of peculiar things about kinds in type synonym and data declarations. For example: {{{ $ /opt/ghc/head/bin/ghci -XTypeInType -XRankNTypes -XTypeOperators GHCi, version 8.1.20160113: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/xnux/.ghci ?> import Data.Kind ?> type Wat (a :: k2) (b :: k3) = forall (f :: k1 -> *). Either (f a) (f b) ?> :i Wat type Wat (a :: k1) (b :: k1) = forall (f :: k1 -> *). Either (f a) (f b) -- Defined at :2:1 }}} This is pretty odd for two reasons. One, the kind {{{k1}}} was never specified (either existentially or as a visible kind binder), so that definition should have been rejected. But even if we do use an existential kind: {{{ ?> type Wat (a :: k2) (b :: k3) = forall k1 (f :: k1 -> *). Either (f a) (f b) ?> :i Wat type Wat (a :: k1) (b :: k1) = forall k2 (f :: k2 -> *). Either (f a) (f b) -- Defined at :4:1 }}} We still see the second issue: GHC thinks that the type variables `a` and `b` have the same kind `k1`, when they should have separate kinds `k1` and `k2`! That behavior is very surprising to me, since it seems like GHC is choosing to unify two kind variables that should be rigid. Note that this doesn't happen if you use explicit kind binders: {{{ type Wat k2 k3 (a :: k2) (b :: k3) = forall k1 (f :: k1 -> *). Either (f a) (f b) :6:74: error: ? Expected kind ?k1?, but ?a? has kind ?k2? ? In the first argument of ?f?, namely ?a? In the first argument of ?Either?, namely ?f a? In the type ?forall k1 (f :: k1 -> *). Either (f a) (f b)? :6:80: error: ? Expected kind ?k1?, but ?b? has kind ?k3? ? In the first argument of ?f?, namely ?b? In the second argument of ?Either?, namely ?f b? In the type ?forall k1 (f :: k1 -> *). Either (f a) (f b)? }}} only when the kinds are specified but not visible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 20:03:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 20:03:18 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.377cad2a1fe540ab026bc0c1f2fe0a1a@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): Replying to [comment:49 thomie]: > rassilon: you seem to know stuff. How to fix dynamic linking on Windows? Some more problems here: #4824 #5620 #7665 #8228. The "easiest" way of fixing this issue is by refactoring the GHC internals in such a way as to minimize the dependencies between the partitions of the GHC base DLL. (in short, removing all need for Haskell source level cyclic imports could help a bunch here) Either that, or come up with an automatic partitioning scheme that could handle cyclic references between the partition DLLs. The PE/COFF limitation of only being able to export 16bits worth of APIs from a dynamic library is the biggest problem of all of these issues. #5620 would only be worth addressing when we have a solution to this issue one way or another. Given that the root of the 16bit exported API problem stems from the PE/COFF specification, it would seem that any alternatives we come up would be conceptually equivalent to our current usages of non-dlopen(or equivalent) dynamic loading/linking that RTS/GHCi do today. In fact the code necessary to fix this issue would probably make that logic even more convoluted and difficult to understand/maintain. (Since the code would need to understand whatever additional sections/per-DLL API functions/etc.. that would allow the code to be relocated and linked properly.) Such a scheme would have additional downsides as well: * It would be (by necessity) be Windows specific. * It would probably completely shatter the mechanism for calling Haskell functions from C/C++ either in the same DLL or another DLL. Of the possible above approaches, I would think an automatic partitioning approach that handled cyclic references between the partitions would be the approach that had the best long term chances of successfully being maintained. Having said that of course, even automatic partitioning is still a non trivial amount of work. Since ideally, Cabal would know about DLL partitioning as well so that when anyone referenced a Haskell package with partitions, Cabal would help (or direct) GHC to link against all of the partition DLLs of that package. Ugh. Maybe it'll be easier once Microsoft lets us push a pull request to Window's dynamic linker to support more than 16bits of ordinals for Windows 20. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 20:17:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 20:17:02 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.91c8780b306484051c133f59eac41900@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by thomie): bgamari: what is the status here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 20:17:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 20:17:14 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.790572e499a98a9b447fe5219994c572@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): Okay, here's my stab at a minimal description of the plan: https://ghc.haskell.org/trac/ghc/wiki/Design/Redundant_Superclass_Warning_Plan Herbert and Edward can fill in if they think I got it correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 20:41:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 20:41:21 -0000 Subject: [GHC] #11453: Kinds in type synonym/data declarations can unexpectedly unify In-Reply-To: <050.b6d1aeccf29fe9a1ce1e81a78207e37f@haskell.org> References: <050.b6d1aeccf29fe9a1ce1e81a78207e37f@haskell.org> Message-ID: <065.13849580032f1d96886458d3d86ac987@haskell.org> #11453: Kinds in type synonym/data declarations can unexpectedly unify -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: TypeInType 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 goldfire): * status: new => closed * resolution: => duplicate Comment: These weirdnesses are all a direct consequence of #11203. They are ''not'' a consequence of `TypeInType`. However, these are very helpful examples in looking at #11203. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 20:42:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 20:42:01 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.1eff3cd394e7a413772dc055f8cf0d00@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): See #11453, which has several examples of weird behavior caused by this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 20:42:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 20:42:26 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.994975be178d3c019cfb8db034ea8db7@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 21:56:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 21:56:13 -0000 Subject: [GHC] #11454: Do not suggest deprecated flags Message-ID: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> #11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- When you misspell the name of a flag, GHC outputs a nice list of similar flags that do exist: {{{ $ ghc-8.0.1 -W-redundant-constraints ghc: unrecognised flag: -W-redundant-constraints did you mean one of: -Wredundant-constraints -Wno-redundant-constraints -fwarn-redundant-constraints }}} But since the `-fwarn` flags are deprecated, they should not be suggested. Neither should any of the other deprecated flags. For a newcomer: the code is `compiler/main/DynFlags.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:16:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:16:53 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.62154fc9b533db30be3d1e0d82be0763@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell (added) Comment: For info, I found a similar bug while trying Shake with GHC 8.0-rc1 provided by hvr (8.0.0.20160111+git.0.497454f). Chopping out the relevant bit leaves: {{{#!hs -- optIntArg :: (Ord a0, Read a0, Show a0) => a0 -> [Char] -> t0 -> (Maybe a0 -> t2) -> Maybe String -> Either [Char] ([t1], t2) optIntArg mn flag a f = maybe (Right ([], f Nothing)) $ \x -> case reads x of [(i,"")] | i >= mn -> Right ([],f $ Just i) _ -> Left $ "the `--" ++ flag ++ "' option requires a number, " ++ show mn ++ " or above" }}} Uncommenting the type signature makes it work. Without, it fails with: {{{ solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Eq a (CDictCan) [D] _ :: Ord a (CDictCan) [D] _ :: Read a (CDictCan) [D] _ :: Show a (CDictCan) [W] hole{a5xW} :: a ~ a (CNonCanonical) [D] _ :: Eq a (CDictCan)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit] }}} Given the size of the code fragment that triggers it, and the fact a number of bugs were found, this might be another useful test case. Tweaking to give: {{{#!hs optIntArg mn flag a f = maybe (Right ([], f Nothing)) $ \x -> case reads x of [(i,"")] | i == mn -> Right ([],f $ Just i) _ -> Left $ "the `--" ++ flag ++ "' option requires a number, or above" }}} I end up with a very different error: {{{ src\Demo.hs:5:41: error: * Couldn't match type `a' with `a1' because type variable `a1' would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: Maybe a1 at src\Demo.hs:5:37-46 Expected type: Maybe a1 Actual type: Maybe a }}} This code compiles fine with GHC 7.10, so seems like a different bug, or different manifestation of the same bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:17:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:17:28 -0000 Subject: [GHC] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives In-Reply-To: <051.c6c45266fc5f87d1eb4c881e200bec98@haskell.org> References: <051.c6c45266fc5f87d1eb4c881e200bec98@haskell.org> Message-ID: <066.26197a2dcdcf3ac0c7cf7d8f05c2cbb3@haskell.org> #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: parallelim 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 thomie): robstewartuk: please submit a patch. See [wiki:WorkingConventions/FixingBugs]. Unfortunately, you'll have to build the compiler to be able to build the documentation, see [wiki:Building/Docs#UsersGuide]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:34:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:34:09 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.69097da904324c6d7c547ad9c225df19@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:37:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:37:02 -0000 Subject: [GHC] #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" Message-ID: <046.0a1104bd4a30d7217d069d9f0b885c64@haskell.org> #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1-rc1 system | 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 first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently: {{{ $ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock- ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set- cover-0.0.8.tar.gz Downloading http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz Resolving dependencies... Configuring enummapset-0.5.2.1... Building enummapset-0.5.2.1... Preprocessing library enummapset-0.5.2.1... [1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o ) ... [4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o ) [5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o ) In-place registering enummapset-0.5.2.1... Running Haddock for enummapset-0.5.2.1... Preprocessing library enummapset-0.5.2.1... ... Registering enummapset-0.5.2.1... Installed enummapset-0.5.2.1 Configuring set-cover-0.0.8... Building set-cover-0.0.8... Preprocessing library set-cover-0.0.8... [ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o ) [ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o ) src/Math/SetCover/Queue.hs:3:1: error: Bad interface file: /home/cabal/lib/x86_64-linux- ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi Something is amiss; requested module enummapset-0.5.2.1 at enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap src/Math/SetCover/Queue.hs:4:1: error: Bad interface file: /home/cabal/lib/x86_64-linux- ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi Something is amiss; requested module enummapset-0.5.2.1 at enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet Failed to install set-cover-0.0.8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:39:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:39:46 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.9d249d9db800e795f621991a054cef35@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): Alright, I am able to reproduce this on `master`, {{{ $ git clone git://github.com/bgamari/impossible-case-alternative-repro repro $ cd repro $ git checkout segfault $ git clone git://github.com/bos/aeson $ cabal install aeson $ ghc -O Main.hs $ ./Main "before eval" Segmentation fault $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:40:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:40:42 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.66cf802105448cb94a45d040883fdccf@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Understood. Right now, I'm mired in the substantial refactor posted in Phab:D1777 (which you believe will also fix "highest" priority #11397). I could perhaps get to this later this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:41:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:41:53 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.97f5110bbbdee522ea6e447f05a5d485@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): The issue here is clearly, {{{#!hs Main.main5 :: (Either () GHC.Prim.Any, Module.JSONState Mytype) -> Either String (Either () Float, Module.JSONState ()) Main.main5 = \ (a31_XcHt :: (Either () GHC.Prim.Any, Module.JSONState Mytype)) -> case a31_XcHt of _ [Occ=Dead] { (a26_XdKv, s'_XdKx) -> case a26_XdKv of _ [Occ=Dead] { Left e1_adOn -> case s'_XdKx of _ [Occ=Dead] { Module.JSONState ds1_XcmP ns'_XagP ds2_XcmS -> Data.Either.Right @ String @ (Either () Float, Module.JSONState ()) (Data.Either.Left @ () @ Float e1_adOn, Module.JSONState @ () (GHC.Types.[] @ String) ns'_XagP GHC.Tuple.()) }; Right x_XdQJ -> case Main.main6 of wild2_00 { } -- uh oh } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:42:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:42:10 -0000 Subject: [GHC] #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" In-Reply-To: <046.0a1104bd4a30d7217d069d9f0b885c64@haskell.org> References: <046.0a1104bd4a30d7217d069d9f0b885c64@haskell.org> Message-ID: <061.410b32a15c2752a0f47f4fb00c16e0a9@haskell.org> #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1-rc1 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 mpickering): Which version of cabal are you using? Sounds like you might need to build from the github repository. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:42:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:42:39 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.599e3a95d62d82b1f4ad014440961a1b@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): For me ghc creates /tmp/cc* files on every linkage: {{{ $ ls -l /tmp/cc* | grep slyfox $ echo 'main = print 1' > a.hs $ inplace/bin/ghc-stage2 --make a.hs $ ls -l /tmp/cc* | grep slyfox -rw------- 1 slyfox users 3295 Jan 18 22:37 /tmp/cch5o5Wp $ cat /tmp/cch5o5Wp -plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccM7O6lz.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a ... }}} Do other people see the ~same contents in orphan /tmp/cc* files? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:44:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:44:23 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.ce9cf178849e74aed2a46ddce459b99d@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): This appears rather early during simplification. Namely after, {{{ SimplMode {Phase = 2 [main], inline, rules, eta-expand, case-of-case} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:45:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:45:41 -0000 Subject: [GHC] #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" In-Reply-To: <046.0a1104bd4a30d7217d069d9f0b885c64@haskell.org> References: <046.0a1104bd4a30d7217d069d9f0b885c64@haskell.org> Message-ID: <061.e1eb7104b1ab54140885c5313705e7f3@haskell.org> #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 8.0.1-rc1 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 thomie): * status: new => closed * resolution: => worksforme Comment: See this email: https://mail.haskell.org/pipermail/ghc- devs/2016-January/010978.html Also available from https://launchpad.net/~hvr/+archive/ubuntu/ghc, if you're on Ubuntu or Debian. Please reopen if it didn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:50:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:50:11 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic Message-ID: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications GHCi | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type applications and the [https://downloads.haskell.org/~ghc/master /users-guide/ghci.html#ghci-cmd-:set%20+c :set +c] command don't play nice {{{#!hs {-# LANGUAGE TypeApplications #-} a = show @Int }}} {{{ % ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> :set +c Prelude> :load Panic.hs [1 of 1] Compiling Main ( Panic.hs, interpreted ) Ok, modules loaded: Main. Collecting type info for 1 module(s) ... Error while getting type info from Main: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): dsExpr:HsTypeOut Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:51:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:51:38 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.e6b524225aaaee3b246aad48e4d619be@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Doesn't happen with `id @Int` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:51:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:51:45 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.d8684e566a0c5d4187e577e624600b24@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): I should note that, distressingly enough, this testcase passes both STG linting and Core linting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 22:59:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 22:59:47 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.08309ed6c5b8697f515b5cf1d0d18c9d@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): It is very considerably easier not to instantiate levity-polymorphic variables with foralls. So that's what I'm doing right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:01:29 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.e68878f621640e48dca55156b0ff7dae@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): It seems to be a gcc/ld bug at least on non-windows. I can create crufty files by running: {{{ $ echo 'main(){}' > a.c $ touch a.rsp $ gcc a.c -o a @a.rsp }}} And /tmp/cc8oGbH4 appears. Support for .rsp files was added in changeset:296bc70b5ff6c853f2782e9ec5aa47a52110345e (#10777) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:02:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:02:08 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.f54507f8f098e7ed9b17ee69eac352ef@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 slyfox): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:06:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:06:54 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.7c5db6e830672a3283158f32ca2544de@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): * Attachment "Parser.diff" added. Parser patch that disambiguates exported variable/type constructors by their subexport -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:11:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:11:39 -0000 Subject: [GHC] #2988: Improve float-in In-Reply-To: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@haskell.org> References: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@haskell.org> Message-ID: <061.9ec707cbd020a5ce6319d46acd7c10d8@haskell.org> #2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:16:17 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.2048a1da49f7130e99ea881173072753@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Filed upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:18:59 -0000 Subject: [GHC] #5916: runST isn't free In-Reply-To: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> References: <044.d958bab6cdf04501b440e190747a91b9@haskell.org> Message-ID: <059.6f3bda8459403a0546d0b1b2d7766fa8@haskell.org> #5916: runST isn't free -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_run/runST Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The new `runRW#` primop is just what the doctor ordered. See 351de169e14ad9277aaca653df4a3753c151f7bb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:24:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:24:30 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.cf009a8d31ddf3e1a19c1dca2ed4606f@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie): Great. Could you please submit it to [wiki:Phabricator], like you did with your previous patch. Then it gets validated automatically (at least, if the buildbot is not over capacity at the time you submit). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:27:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:27:07 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.454c9ec265c45d1e3ae37b52bedca7be@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): I see two possible ways to resolve this issue. * The first way is to change GHC grammar (as shown in attached Parser.diff) to distinguish between `(-.->)` and `(-.->)(..)` in export lists: the first construct must be recognized as variable constructor, while the second must be type constructor (because it has `(..)`). With this patch GHC can parse the reported program (and passes all existing tests). Note that the patch does not add any new conflicts. However, it is ugly: one has to lift low-level nonterminals (variable and type names) all the way up to export lists: parser cannot decide whether it is variable or type name until it sees subexport. * The second way (I have no example patch yet) would be to free grammar of all this mess: parse any constructor in export list as just some constructor (probably with subexport) and decide which kind it is later. So you see, this patch is kind of a demonstration that LALR grammars are capable of parsing such things. I'm not happy with this solution; I'd rather try the second way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:30:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:30:34 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.20f7f14628039c1bd24d4183368ae068@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie): Ah, ok. Take your time. For your final patch, please add the example from the description as a test, see [wiki:Building/RunningTests/Adding], or look at an existing example in `testsuite/tests/parser`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:32:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:32:22 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.347b91cc7ee6ceec5fcd230e720ebf33@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): Sure! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:42:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:42:34 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.2688319a16405c2d0f8fffdccf407014@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1799 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D1799 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 18 23:58:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jan 2016 23:58:40 -0000 Subject: [GHC] #11457: Run type-checker plugins before GHC's solver Message-ID: <049.a8fb4e5f5bcb03aebd9c2ea03a73390b@haskell.org> #11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: plugin | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an odd use-case for type-checker plugins: rejecting ''valid'' programs that the user doesn't like, for example, programs that use a class instance with confusing behavior (like the functor/traversable instances on tuples). Unfortunately, we can't write such a plugin at the moment because GHC runs its own solver first, and will (I think) discharge any dictionary constraints before the plugin can run. If instead we run the plugins first, a plugin could mark undesired instances as insoluble. See the discussion at http://mail.haskell.org/pipermail/libraries/2016-January/026602.html for the original motivation. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 01:37:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 01:37:25 -0000 Subject: [GHC] #7888: Impredicativity flag needed more often In-Reply-To: <047.78aeef62d9867c1f320bbe27154c71a9@haskell.org> References: <047.78aeef62d9867c1f320bbe27154c71a9@haskell.org> Message-ID: <062.68c0cc8f5f6f9c2aabead1816b91560f@haskell.org> #7888: Impredicativity flag needed more often -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T7888 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is at odds with #11431. I'm going with #11431 as that's more consistent, as discussed on that ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 02:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 02:08:26 -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.22909d546dd48d587084ddd8c525ec9f@haskell.org> #11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: plugin 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): We need to intertwine the various aspects, and I don't know how that works with the plugin infrastructure. For example, if we have (hypothetically) {{{#!hs import Prelude.Extras {-# SuppressInstance Functor ((,) a) #-} foo :: (p -> q) -> Lift1 ((,) x) p -> Lift1 ((,) x) q foo = fmap }}} GHC will recognize a `Functor (Lift1 ((,) x))` constraint. We need the usual constraint solver to run far enough to determine that this requires `Functor ((,) x)` before we can step in and reject the solution. ---- Note that the suppression regime has not yet gone far enough for a full-on proposal yet. Some things people might want: 1. Suppress or warn about an instance unconditionally. This is clearly the simplest case, and covers the immediate demand. 2. Suppress or warn about an instance if a certain constraint *can* be satisfied. This seems a bit shady, but it may have applications. 3. Suppress or warn about use of an instance if a certain constraint *cannot* be satisfied. That is, add that constraint to the instance temporarily. This might be desirable if an instance is *implementable* without the given constraint, but doesn't really make *sense* without it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 03:23:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 03:23:39 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.00bfb503dd56b907457cb2daffc3d761@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): I think I found the problem. I'll keep debugging this tomorrow.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 04:36:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 04:36:34 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.1aa4b0a533e2cab4ab35c717223ffde3@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:00:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:00:25 -0000 Subject: [GHC] #11448: New --frontend mode is only partially documented In-Reply-To: <045.498508dda538a30f2c57476495771712@haskell.org> References: <045.498508dda538a30f2c57476495771712@haskell.org> Message-ID: <060.8a11fbfb4dfd76c1a09a1fd778d44ba1@haskell.org> #11448: New --frontend mode is only partially documented -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1793 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aff51af1d747f88a140f435882efcd46b47b50af/ghc" aff51af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aff51af1d747f88a140f435882efcd46b47b50af" users-guide: Begin documenting --frontend Reviewers: austin Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D1793 GHC Trac Issues: #11448 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:00:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:00:25 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.a154873c918b9a66111378afdfab671f@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Phab:D1794 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d2ea7f94cb21662857cd50c95ff41943e5911a9b/ghc" d2ea7f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d2ea7f94cb21662857cd50c95ff41943e5911a9b" Hide derived OccNames from user This hides derived OccNames from the Names returned from runDeclsWithLocation and clarifies the documentation. This is done to ensure that these names (originating from, e.g., derived Generic instances and type representation bindings) don't show up in ghci output when run with `:set +t`. This fixes #11051. Test Plan: Validate with included tests Reviewers: austin Reviewed By: austin Subscribers: thomie, hvr Differential Revision: https://phabricator.haskell.org/D1794 GHC Trac Issues: #11051 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:07:47 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application Message-ID: <046.9e988e804957302749d23e8054557bb0@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- Consider {{{ -- optIntArg :: (Maybe Int -> t2) -> (t2,t2) optIntArg f = (f Nothing, f (Just True)) }}} This is rejected (by HEAD) {{{ T11379a.hs:5:30: error: * Couldn't match type `a' with `Bool' `a' is a rigid type variable bound by a type expected by the context: forall a. Maybe a at T11379a.hs:5:30 Expected type: forall a. Maybe a Actual type: Maybe Bool * In the first argument of `f', namely `(Just True)' In the expression: f (Just True) In the expression: (f Nothing, f (Just True)) }}} but if you put the tuple components the other way round, it works fine {{{ optIntArg f = (f (Just True), f Nothing) }}} Adding the commented-out signature also makes it work fine. I'm almost certain that this is caused by visible type application; perhaps `Nothing` gets delayed instantiation, and then `f`'s type becomes `forall a. Maybe a`. Utterly bogus. I suspect it'll be fixed by Richards `ReturnTv` work, but let's make sure it is. We can't release this!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:08:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:08:17 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application In-Reply-To: <046.9e988e804957302749d23e8054557bb0@haskell.org> References: <046.9e988e804957302749d23e8054557bb0@haskell.org> Message-ID: <061.2e70c2f218768e9d7b8c6cfbcb0e69d7@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | 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 simonpj): * owner: => goldfire * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:09:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:09:41 -0000 Subject: [GHC] #11379: Solver hits iteration limit in code without recursive constraints In-Reply-To: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> References: <046.6baf8726906a35ddc433fd25475ca73d@haskell.org> Message-ID: <061.307c1199a098e1450da3f820c878df41@haskell.org> #11379: Solver hits iteration limit in code without recursive constraints -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Neil, thank you. You have found a much more serious and quite unrelated bug, which I've created as #11458. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:42:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:42:48 -0000 Subject: [GHC] #5063: unix package has untracked dependency on libbsd In-Reply-To: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> References: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> Message-ID: <060.21dd2f52a911cd1dce84a2c427be74e8@haskell.org> #5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: upstream Priority: low | Milestone: 8.2.1 Component: Core Libraries | Version: 7.0.3 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: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:15 bgamari]: > What is the status of this? It seems like there have been no patches submitted upstream to resolve this. Tbh, based on > If the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems. This doesn't sound like an issue in `unix`, but rather an inherent issue with binaries built on a build-environment which is different from the target/deployment environment. I wouldn't consider this a bug in `unix`. It works as designed, as `unix` when configured tries to use as many features as available in the build environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 08:52:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 08:52:20 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.ace8376f6c56b6214addb72f27f45635@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 09:13:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 09:13:31 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.dd3aa267a0a3b8fc58a08ed7a7f0add2@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): > So on ELF platforms -split-sections should be ready to replace -split- objs; further testing and investigation is necessary on Windows and OS X. OS X should just use the built-in subsection support. For non-Linux ELF platforms, an issue is that `--gc-sections` (under that name) is only available from GNU ld, other linkers might not have it or might call it something else. That means dropping `-split-objs` probably would leave some platforms without dead-code stripping at all. It should be good to go with GNU ld on non-Windows though. And for unixes without GNU ld we could get configure to check if the linker has something like `--gc-sections` and how to activate it. (Looks like e.g. Solaris has a `-z discard-unused=sections` flag.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 09:20:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 09:20:14 -0000 Subject: [GHC] #11459: Rather terrible error message due to excessive kind polymorphism Message-ID: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> #11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- When fixing up `cassava` for GHC 8.0 I found I needed to enable `PolyKinds` due to an unrelated change encountered a rather vexing error. Consider this, {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, KindSignatures, RankNTypes #-} module Hi where -- | Failure continuation. type Failure f r = String -> f r -- | Success continuation. type Success a f r = a -> f r newtype Parser a = Parser { unParser :: forall f r. Failure f r -> Success a f r -> f r } runParser :: Parser a -> Either String a runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} With GHC 7.10 this failed with the quite comprehensible, {{{ Hi.hs:21:20: A newtype constructor cannot have existential type variables Parser :: forall a (k :: BOX). (forall (f :: k -> *) (r :: k). Failure f r -> Success a f r -> f r) -> Parser a In the definition of data constructor ?Parser? In the newtype declaration for ?Parser? }}} However, with 8.0 the compiler curtly informs you that, {{{ Hi.hs:29:26: error: ? Couldn't match kind ?GHC.Prim.Any? with ?*? When matching the kind of ?Either String? ? In the second argument of ?unParser?, namely ?left? In the expression: unParser p left right In an equation for ?runParser?: runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} As expected, adding a kind signature to `Parser`'s type variables fixed the issue but the error doesn't help the user realize this nearly as much as it could. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 09:21:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 09:21:35 -0000 Subject: [GHC] #11459: Rather terrible error message due to excessive kind polymorphism In-Reply-To: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> References: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> Message-ID: <061.d3cf93d123428593fe5fa5d3a66844b1@haskell.org> #11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When fixing up `cassava` for GHC 8.0 I found I needed to enable > `PolyKinds` due to an unrelated change encountered a rather vexing error. > > Consider this, > {{{#!hs > {-# LANGUAGE DataKinds, PolyKinds, KindSignatures, RankNTypes #-} > > module Hi where > > -- | Failure continuation. > type Failure f r = String -> f r > -- | Success continuation. > type Success a f r = a -> f r > > newtype Parser a = Parser { > unParser :: forall f r. > Failure f r > -> Success a f r > -> f r > } > > runParser :: Parser a -> Either String a > runParser p = unParser p left right > where > left !errMsg = Left errMsg > right !x = Right x > }}} > > With GHC 7.10 this failed with the quite comprehensible, > {{{ > Hi.hs:21:20: > A newtype constructor cannot have existential type variables > Parser :: forall a (k :: BOX). > (forall (f :: k -> *) (r :: k). > Failure f r -> Success a f r -> f r) > -> Parser a > In the definition of data constructor ?Parser? > In the newtype declaration for ?Parser? > }}} > > However, with 8.0 the compiler curtly informs you that, > {{{ > Hi.hs:29:26: error: > ? Couldn't match kind ?GHC.Prim.Any? with ?*? > When matching the kind of ?Either String? > ? In the second argument of ?unParser?, namely ?left? > In the expression: unParser p left right > In an equation for ?runParser?: > runParser p > = unParser p left right > where > left !errMsg = Left errMsg > right !x = Right x > }}} > > As expected, adding a kind signature to `Parser`'s type variables fixed > the issue but the error doesn't help the user realize this nearly as much > as it could. New description: When fixing up `cassava` for GHC 8.0 I found I needed to enable `PolyKinds` due to an unrelated change (namely in order to apply `Proxy` to something of kind `GHC.Generics.Meta`, which will be quite a common refactoring in 8.0) encountered a rather vexing error. Consider this, {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, KindSignatures, RankNTypes #-} module Hi where -- | Failure continuation. type Failure f r = String -> f r -- | Success continuation. type Success a f r = a -> f r newtype Parser a = Parser { unParser :: forall f r. Failure f r -> Success a f r -> f r } runParser :: Parser a -> Either String a runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} With GHC 7.10 this failed with the quite comprehensible, {{{ Hi.hs:21:20: A newtype constructor cannot have existential type variables Parser :: forall a (k :: BOX). (forall (f :: k -> *) (r :: k). Failure f r -> Success a f r -> f r) -> Parser a In the definition of data constructor ?Parser? In the newtype declaration for ?Parser? }}} However, with 8.0 the compiler curtly informs you that, {{{ Hi.hs:29:26: error: ? Couldn't match kind ?GHC.Prim.Any? with ?*? When matching the kind of ?Either String? ? In the second argument of ?unParser?, namely ?left? In the expression: unParser p left right In an equation for ?runParser?: runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} As expected, adding a kind signature to `Parser`'s type variables fixed the issue but the error doesn't help the user realize this nearly as much as it could. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 09:21:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 09:21:55 -0000 Subject: [GHC] #11459: Rather terrible error message due to excessive kind polymorphism In-Reply-To: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> References: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> Message-ID: <061.fa43dfecb31cdd74b5c011e5dddf34bb@haskell.org> #11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When fixing up `cassava` for GHC 8.0 I found I needed to enable > `PolyKinds` due to an unrelated change (namely in order to apply `Proxy` > to something of kind `GHC.Generics.Meta`, which will be quite a common > refactoring in 8.0) encountered a rather vexing error. > > Consider this, > {{{#!hs > {-# LANGUAGE DataKinds, PolyKinds, KindSignatures, RankNTypes #-} > > module Hi where > > -- | Failure continuation. > type Failure f r = String -> f r > -- | Success continuation. > type Success a f r = a -> f r > > newtype Parser a = Parser { > unParser :: forall f r. > Failure f r > -> Success a f r > -> f r > } > > runParser :: Parser a -> Either String a > runParser p = unParser p left right > where > left !errMsg = Left errMsg > right !x = Right x > }}} > > With GHC 7.10 this failed with the quite comprehensible, > {{{ > Hi.hs:21:20: > A newtype constructor cannot have existential type variables > Parser :: forall a (k :: BOX). > (forall (f :: k -> *) (r :: k). > Failure f r -> Success a f r -> f r) > -> Parser a > In the definition of data constructor ?Parser? > In the newtype declaration for ?Parser? > }}} > > However, with 8.0 the compiler curtly informs you that, > {{{ > Hi.hs:29:26: error: > ? Couldn't match kind ?GHC.Prim.Any? with ?*? > When matching the kind of ?Either String? > ? In the second argument of ?unParser?, namely ?left? > In the expression: unParser p left right > In an equation for ?runParser?: > runParser p > = unParser p left right > where > left !errMsg = Left errMsg > right !x = Right x > }}} > > As expected, adding a kind signature to `Parser`'s type variables fixed > the issue but the error doesn't help the user realize this nearly as much > as it could. New description: When fixing up `cassava` for GHC 8.0 I found I needed to enable `PolyKinds` due to an unrelated change (namely in order to apply `Proxy` to something of kind `GHC.Generics.Meta`, which will be quite a common refactoring in 8.0) encountered a rather vexing error. Consider this, {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, KindSignatures, RankNTypes #-} module Hi where -- | Failure continuation. type Failure f r = String -> f r -- | Success continuation. type Success a f r = a -> f r newtype Parser a = Parser { unParser :: forall f r. Failure f r -> Success a f r -> f r } runParser :: Parser a -> Either String a runParser p = unParser p Left Right }}} With GHC 7.10 this failed with the quite comprehensible, {{{ Hi.hs:21:20: A newtype constructor cannot have existential type variables Parser :: forall a (k :: BOX). (forall (f :: k -> *) (r :: k). Failure f r -> Success a f r -> f r) -> Parser a In the definition of data constructor ?Parser? In the newtype declaration for ?Parser? }}} However, with 8.0 the compiler curtly informs you that, {{{ Hi.hs:29:26: error: ? Couldn't match kind ?GHC.Prim.Any? with ?*? When matching the kind of ?Either String? ? In the second argument of ?unParser?, namely ?left? In the expression: unParser p left right In an equation for ?runParser?: runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} As expected, adding a kind signature to `Parser`'s type variables fixed the issue but the error doesn't help the user realize this nearly as much as it could. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 10:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 10:10:09 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.17a4a7b7d1801831afd8fb3aa06f7fc8@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Phab:D1794 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `master` and `ghc-8.0` (as d2ea7f94cb21662857cd50c95ff41943e5911a9b). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 10:10:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 10:10:48 -0000 Subject: [GHC] #11448: New --frontend mode is only partially documented In-Reply-To: <045.498508dda538a30f2c57476495771712@haskell.org> References: <045.498508dda538a30f2c57476495771712@haskell.org> Message-ID: <060.5ffb7437059a2312299058c185ee4c61@haskell.org> #11448: New --frontend mode is only partially documented -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1793 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as aff51af1d747f88a140f435882efcd46b47b50af. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 10:38:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 10:38:12 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.391465506cfc19984834d5f3ed5f63ff@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1800 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 11:13:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 11:13:50 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.441b63e492e6b4206c244eb367c69bc9@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I have fully working `-split-sections` on Windows. To make it possible quite recently I've fixed [https://ghc.haskell.org/trac/ghc/ticket/11388 a blocker bug in GHC] (thanks to Phyx for putting it in). But also we need the very latest binutils because of [https://sourceware.org/bugzilla/show_bug.cgi?id=19440 the bug in binutils] I've helped to fix just recently. And the final thing to make it all work are correct linker scripts (generated from the single `pep.sc` template), which solve [https://sourceware.org/bugzilla/show_bug.cgi?id=19254 section merging problem]. I've incorporated it in my own patched version of binutils but I still didn't propose the corresponding patch to upstream binutils. I have no much spare time at the moment, and this patch also contains an extra bugfix for current binutils, thus some extra work is required here, but if the need is urgent I'll try to wrap it in coming days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 11:19:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 11:19:18 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.595fc965d1ba6ed54a68369c74a0bc15@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, these tests all fail with segmentation faults despite passing Core Lint with Phab:D1656, {{{ TEST="literals parsed landmines T11430 T10313 comments parseTree annotations listcomps T8628 T8639_api T10508_api T7478 T1969 T9872d" }}} They all seem to share the fact that they use the GHC API. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 11:20:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 11:20:41 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.0af20e1ccefb5fc9182a19408eda8e4b@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While looking for another bug I stumbled upon #10343, which describes another, related hole in our typeable story: there is no way to extract a representation of the kind of a type. This seems quite straightforward to provide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 11:25:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 11:25:03 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.a498aff232052bb2d905406d6d24cbe5@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"9d33adb6f352ad4e488067a8756928b3778920e0/ghc" 9d33adb6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d33adb6f352ad4e488067a8756928b3778920e0" Check InScopeSet in substTy and provide substTyUnchecked This adds sanity checks to `substTy` that implement: > when calling substTy subst ty it should be the case that the in-scope > set in the substitution is a superset of > * The free vars of the range of the substitution > * The free vars of ty minus the domain of the substitution and replaces violators with unchecked version. The violators were found by running the GHC test suite. This ensures that I can work on this incrementally and that what I fix won't be undone by some other change. It also includes a couple of fixes that I've already done. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1792 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 11:52:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 11:52:03 -0000 Subject: [GHC] #11460: OverloadedStrings cause error in annotation Message-ID: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> #11460: OverloadedStrings cause error in annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | 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: -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# ANN module "HLint: ignore Eta reduce" #-} main = putStrLn "hello" }}} results in {{{ /tmp/Foo.hs:3:1: No instance for (Data.Data.Data a0) arising from an annotation The type variable ?a0? is ambiguous Note: there are several potential instances: instance (Data.Data.Data a, Data.Data.Data b) => Data.Data.Data (Either a b) -- Defined in ?Data.Data? instance Data.Data.Data t => Data.Data.Data (Data.Proxy.Proxy t) -- Defined in ?Data.Data? instance (GHC.Types.Coercible a b, Data.Data.Data a, Data.Data.Data b) => Data.Data.Data (Data.Type.Coercion.Coercion a b) -- Defined in ?Data.Data? ...plus 31 others In the annotation: {-# ANN module "HLint: ignore Eta reduce" #-} /tmp/Foo.hs:3:16: No instance for (Data.String.IsString a0) arising from the literal ?"HLint: ignore Eta reduce"? The type variable ?a0? is ambiguous Note: there is a potential instance available: instance Data.String.IsString [Char] -- Defined in ?Data.String? In the annotation: {-# ANN module "HLint: ignore Eta reduce" #-} }}} when using GHC 7.10.3, and similar for GHC 8 RC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 12:09:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 12:09:12 -0000 Subject: [GHC] #11460: OverloadedStrings cause error in annotation In-Reply-To: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> References: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> Message-ID: <059.de9bdbae16f72aabd1edf4381ffee2b9@haskell.org> #11460: OverloadedStrings cause error in annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by nomeata): This is actually expected. An annotation can be of any data type; I quote > Any expression that has both Typeable and Data instances may be attached to a top-level value binding using an ANN pragma. So the error message is fine. The work-around is to add `::String` afterwards. Or is there a version of GHC that behaved differently? No one could see this ticket as a request to make this a bit more smooth, e.g. by defaulting to `String` within an `ANN` or something. Is it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 12:12:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 12:12:58 -0000 Subject: [GHC] #9920: Segfault in arm binary with llvm 3.5 In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.3528a99c921222690481f97732a8ba22@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+------------------------------ Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by nomeata): > We probably should have merged that configure check into ghc-7.10 but it's water under the bridge now. JFTR, the configure script made it into ghc-7.10.3, at least I can see it at {{{ checking for llc-3.4... /usr/bin/llc-3.4 checking for opt-3.4... /usr/bin/opt-3.4 checking whether bootstrap compiler is affected by bug 9439... no checking if llvm version is affected by bug 9920... yes configure: error: in `/?PKGBUILDDIR?': configure: error: Cannot compile for ARM with llc-3.5. See GHC trac ticket #9920. See `config.log' for more details debian/rules:50: recipe for target 'override_dh_auto_configure' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.10.3-6~bpo8%2B1&stamp=1453205456 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 12:17:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 12:17:19 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.6002ee67a0cee3936091abc431167146@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Gershom. I have revised [wiki:Design/Warnings] to express comment:10 too. I suggest that others concentrate on [wiki:Design/Warnings], including the timing aspects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 12:25:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 12:25:32 -0000 Subject: [GHC] #11460: OverloadedStrings cause error in annotation In-Reply-To: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> References: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> Message-ID: <059.6e11c2b1862531746905b206fdca7f87@haskell.org> #11460: OverloadedStrings cause error in annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by alanz): In the parser, we have {{{ aexp2 :: { LHsExpr RdrName } : qvar { sL1 $1 (HsVar $! $1) } | qcon { sL1 $1 (HsVar $! $1) } | ipvar { sL1 $1 (HsIPVar $! unLoc $1) } | overloaded_label { sL1 $1 (HsOverLabel $! unLoc $1) } | literal { sL1 $1 (HsLit $! unLoc $1) } -- This will enable overloaded strings permanently. Normally the renamer turns HsString -- into HsOverLit when -foverloaded-strings is on. -- | STRING { sL (getLoc $1) (HsOverLit $! mkHsIsString (getSTRINGs $1) -- (getSTRING $1) placeHolderType) } }}} The annotation expression in this case is parsed as a `HsString`, and the comment seems to indicate that the renamer should be making the `HsString` into an `HsOverLit` when `OverloadedStrings` is active, which I suspect is not happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 13:44:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 13:44:40 -0000 Subject: [GHC] #2988: Improve float-in In-Reply-To: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@haskell.org> References: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@haskell.org> Message-ID: <061.775a906282f416271cd8f03add596c65@haskell.org> #2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 6.10.1 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 goldfire): If you're taking this on, see also #11197, which will likely be fixed by improvements to floating-in. I don't think either of these bugs is dependent on the other exactly, but it would probably be easy to fix them both at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 13:45:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 13:45:02 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.807a93ce1a7e72f723143cf67791fd8c@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): See also #2988, which discusses other improvements to floating-in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 13:47:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 13:47:29 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application In-Reply-To: <046.9e988e804957302749d23e8054557bb0@haskell.org> References: <046.9e988e804957302749d23e8054557bb0@haskell.org> Message-ID: <061.74ae2cec64fef66738bcc698f83ad590@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes. This is a `ReturnTv` problem. Fix is nearly done -- I'm just going through the testsuite today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 13:56:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 13:56:08 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.3f7393d3944594f49004fa4936843834@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 14:47:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 14:47:57 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.6d71f13b7d46bd4236b6921db21fe949@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): Ben says that with with GHC 7.10 you should just be able to do {{{ $ git clone git://github.com/bgamari/impossible-case-alternative-repro repro $ cd repro $ git checkout master $ cabal install --with- ghc=/home/simonpj/5builds/ghc-7.10-branch/inplace/bin/ghc-stage2 }}} and get the "impossible case alternative" error message. Simpler because 7.10 can work with older packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 15:03:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 15:03:04 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.bbc27879453045de4ef250869e7a8a06@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by ekmett): It is worth noting that we've developed a sort of culture of signaling intent with the names of those variables, when a Haskell programmer sees 'a' or 'b' they usually expect something of kind *, f as something of kind * -> *, etc. Is it right? Arguably not, but it is useful. If we're forced to replace all of those with _'s a lot of signal will be lost. There is also a concern that a warning here is something users won't be able to act on if they want to work at all on older compilers that didn't allow _s there. I don't have a concrete counter-proposal, but I do feel ill at ease. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 15:06:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 15:06:33 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.ea5128c6b831a5f3e3c0550e7fac8c09@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): It appears that this, {{{#!hs (\ (a48_aeBK :: (Either () Int, Module.JSONState Double)) -> case a48_aeBK of _ [Occ=Dead] { (a1_aeN0, s'_aeN1) -> case a1_aeN0 of _ [Occ=Dead] { Left l_aeDR -> ks_XeD2 (Data.Either.Left @ () @ Int l_aeDR, s'_aeN1); Right r_aeDU -> ks_XeD2 (Data.Either.Right @ () @ Int r_aeDU, s'_aeN1) } }) }}} is getting simplified to, {{{#!hs (\ (a48_aeBK :: (Either () Int, Module.JSONState Double)) -> case a48_aeBK of _ [Occ=Dead, Dmd=] { (a1_aeN0 [Dmd=], s'_aeN1 [Dmd=]) -> case a1_aeN0 of _ [Occ=Dead, Dmd=] { Left l_aeDR -> case s'_aeN1 of _ [Occ=Dead] { Module.JSONState ww_shDN ww_shDO ww_shDP -> Control.Exception.Base.runtimeError @ (Either String (Either () Int, Module.JSONState ())) "Impossible case alternative"# }; Right r_aeDU -> case s'_aeN1 of _ [Occ=Dead] { Module.JSONState ww_shDN ww_shDO ww_shDP -> Data.Either.Right @ String @ (Either () Int, Module.JSONState ()) (a1_aeMD, Module.JSONState @ () (GHC.Types.[] @ String) ww_shDO GHC.Tuple.()) } } }) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 15:58:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 15:58:22 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.c4a88c9633a60d7ac4e299c8e9d75934@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): You can always use `_f` to signal your intent. Just like at the term level. We never warn about unused variables starting with an underscore. Does that address your concern? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 16:18:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 16:18:16 -0000 Subject: [GHC] #11461: Allow pattern synonyms to be bundled with type classes? Message-ID: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> #11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One can very nearly get associated pattern synonyms by defining suitably polymorphic pattern synonyms. However, they are not quite associated as there's no way to bundle them with the class. This isn't as good as "proper" support but it would be an easy thing to implement for now if people think it worthwhile. For a concrete example, `Null` is an associated pattern synonym in this style but the following program doesn't compile because it is disallowed to bundle a pattern synonym with a type class. {{{ {-# LANGUAGE PatternSynonyms #-} module Foo(Nullable(Null)) where import Data.Maybe class Nullable f where null :: f a -> Bool instance Nullable (Maybe a) where null = isNothing pattern Null :: Nullable f => f a pattern Null = (null -> True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 17:33:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 17:33:24 -0000 Subject: [GHC] #11461: Allow pattern synonyms to be bundled with type classes? In-Reply-To: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> References: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> Message-ID: <064.1f1f8a66b1a267d5102e3ac538b80130@haskell.org> #11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): How does this relate to #8583? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 17:35:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 17:35:47 -0000 Subject: [GHC] #11461: Allow pattern synonyms to be bundled with type classes? In-Reply-To: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> References: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> Message-ID: <064.96bb98743347c3486e8bb57e623e0e5d@haskell.org> #11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): Did you mean {{{#!hs instance Nullable Maybe where null = isNothing pattern Null :: Nullable f => f a pattern Null <- (null -> True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:03:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:03:02 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.b7c76e5de9e1324c4047fef7b2c2a46c@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by ekmett): That can be used to work around this particular concern somewhat, though the mangled names will show up in haddocks and :t and the like, making things a lot noisier. In contrast, the stuff that happens at the value level doesn't make it into the documentation. I'm much more concerned by the mention that we may want to start applying this reasoning to instances, however. > Currently GHC does not warn about type variables bound in the instance head but unused in the where part. Fixing that might be a good idea [snip] There one can argue that those type variables are serving multiple roles. Consider that {{{ instance Foo (a,a) }}} is quite different than {{{ instance a ~ b => Foo (a,b) }}} The fact that there are multiple type variables is actually providing information about what is required to unify with what. The instance head interacts with 'itself' in that way. The relationships between the type variables that show up in the signature matter, even if they never appear in the body itself. At the value level patterns are forced to be linear, multiple uses aren't a concern, but at least in instance heads non-linear patterns arise rather frequently, so that may make it more palatable to not try to shoehorn instance heads into this same uniform handling. Also, if dealing with the fact that every type family is going to start setting off alarm bells is bad, forcing a change on probably 95% of the instances out there is likely to cause panic in the streets. ;) It'd also show up in mangled form throughout the haddocks, creating an uncomfortable tension between seeing the warning and providing pretty documentation. That is less of a concern for type instances and class associated types, but mostly just because there are a lot fewer of those. My primary concern is that it isn't obvious to me that even a single user error in the wild will actually be caught by the change, in exchange for all of this mangling. I'm concerned that it seems like a lot of make-work for users and the end state isn't really any nicer than the one we started in, hence my unease above. We make things a little more strict for library authors, but make things uglier for users. I'd personally be okay with changing all my code around to work with these type families and type synonym warnings. That said, doing the same with instances seems like it would be a pretty radical departure from existing practice, and I think once we start doing this to `type`, we'll start eyeballing `data` and `newtype` next, and I can see a lot of code and documentation getting uglier with little upside and it getting worse the farther down that road we travel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:08:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:08:03 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.2aaa2262e2eb60f1860c1a0f7c922caa@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): * Attachment "SmallExample.hs" added. Small example triggering the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:08:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:08:14 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.829cfea893e27351020fba0774adfdda@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): I tried to break down the input data and arrieved at the following program triggering this bug. I derived it by taking the core before the bad transformation and simplified it. It still fails with an impossible case alternative when compiled with optimizations, but works without themIt is a lot smaller than the original code, so hopefully this helps in tracking down this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:31:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:31:15 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.e9b2d045f6156fe60a50bca99ea39ead@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 thomie): jscholl: nice work. {{{ $ ghc-head SmallExample.hs -fforce-recomp -O [1 of 1] Compiling Main ( SmallExample.hs, SmallExample.o ) Linking SmallExample ... $ ./SmallExample SmallExample: Impossible case alternative }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:42:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:42:37 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.d2ce9e58b07ba47423934ba5668558b8@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:5 awson]: > I have fully working `-split-sections` on Windows. That's awesome! Thank you for working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:56:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:56:47 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.776ca13136c9af3e839a158348602fb4@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1799 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ?mer Sinan A?acan ): In [changeset:"952eda2ec98e6fde27d25a8c6f398674062e398e/ghc" 952eda2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="952eda2ec98e6fde27d25a8c6f398674062e398e" Fix IfaceType generation for TyCons without TyVars - This is only used for printing purposes (in :browse etc.). - Fixes #11266. Reviewers: goldfire, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1799 GHC Trac Issues: #11266 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 19:57:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 19:57:44 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.d868e61c941726f3d5658040be854860@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1799 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 20:02:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 20:02:29 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.082fd805adabd150afb753ceb19ff0c9@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1799 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 21:26:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 21:26:02 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.8c994a47816ad62a4fbc320e950b43e0@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by glaubitz): Another m68k porter showed me today that this bug isn't unique to ghcb but was also found in Erlang: > http://www.grep.be/blog/en/computer/debian/m68k/broken_c_code/ > https://lists.debian.org/debian-68k/2007/12/msg00078.html Wouter's analysis confirms what has being sad in this bug report. The code in question is basically violating the C standard and the fact that it doesn't result in problems is just luck. Who knows we might have new architectures or compilers in the future which will behave differently and therefore this bug might become visible again unless it is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 21:51:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 21:51:51 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.d39ea9287f049ca5a65dd9ae602b8601@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): niteria: this commit is causing some test failures on Travis: {{{ Unexpected failures: ghci.debugger/scripts T2740 [bad stderr] (ghci) ghci.debugger/scripts break001 [bad stderr] (ghci) ghci.debugger/scripts break003 [bad stderr] (ghci) ghci.debugger/scripts break005 [bad stderr] (ghci) ghci.debugger/scripts break006 [bad stderr] (ghci) ghci.debugger/scripts break009 [bad stdout] (ghci) ghci.debugger/scripts break010 [bad exit code] (ghci) ghci.debugger/scripts break011 [bad stdout] (ghci) ghci.debugger/scripts break012 [bad stderr] (ghci) ghci.debugger/scripts break017 [bad stdout] (ghci) ghci.debugger/scripts break018 [bad stderr] (ghci) ghci.debugger/scripts break020 [bad stderr] (ghci) ghci.debugger/scripts break021 [bad stderr] (ghci) ghci.debugger/scripts break026 [bad stderr] (ghci) ghci.debugger/scripts break027 [bad stderr] (ghci) ghci.debugger/scripts break028 [bad stderr] (ghci) ghci.debugger/scripts dynbrk002 [bad stderr] (ghci) ghci.debugger/scripts hist001 [bad stderr] (ghci) ghci.debugger/scripts print003 [bad stderr] (ghci) ghci.debugger/scripts print005 [bad stderr] (ghci) ghci.debugger/scripts print006 [bad stderr] (ghci) ghci.debugger/scripts print008 [bad stderr] (ghci) ghci.debugger/scripts print010 [bad stderr] (ghci) ghci.debugger/scripts print018 [bad stderr] (ghci) ghci.debugger/scripts print019 [bad stderr] (ghci) ghci.debugger/scripts print022 [bad stderr] (ghci) ghci.debugger/scripts print025 [bad stderr] (ghci) ghci.debugger/scripts print029 [bad stderr] (ghci) ghci.debugger/scripts print030 [bad stderr] (ghci) ghci.debugger/scripts print031 [bad stderr] (ghci) ghci.debugger/scripts print032 [bad stderr] (ghci) ghci.debugger/scripts result001 [bad stderr] (ghci) ghci.debugger/scripts/break022 break022 [bad stderr] (ghci) indexed-types/should_compile T3023 [exit code non-0] (normal) overloadedrecflds/ghci overloadedlabelsghci01 [bad stdout] (ghci) polykinds T6015 [exit code non-0] (normal) polykinds T6015a [exit code non-0] (normal) polykinds T6068 [bad stderr] (ghci) polykinds T7332 [exit code non-0] (normal) typecheck/should_compile T4969 [exit code non-0] (normal) typecheck/should_compile tc125 [exit code non-0] (normal) typecheck/should_compile tc126 [exit code non-0] (normal) typecheck/should_compile tc152 [exit code non-0] (normal) typecheck/should_compile tc180 [exit code non-0] (normal) typecheck/should_compile tc187 [exit code non-0] (normal) typecheck/should_fail tcfail093 [exit code non-0] (normal) }}} Here's one of them: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160119 for x86_64-unknown-linux): ASSERT failed! CallStack (from ImplicitParams): assertPprPanic, called at compiler/types/TyCoRep.hs:1827:61 in ghc:TyCoRep substTy, called at compiler/typecheck/FunDeps.hs:289:35 in ghc:FunDeps in_scope InScope [a3vr :-> k_a3vr, a3vs :-> a_a3vs, a3wU :-> t_a3wU[tau:3], a3wV :-> t_a3wV[tau:3]] tenv [a3vr :-> TYPE t_a3wU[tau:3], a3vs :-> t_a3wV[tau:3]] cenv [] ty b_a3vt needInScope [a3vt :-> b_a3vt] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} See: https://s3.amazonaws.com/archive.travis-ci.org/jobs/103319396/log.txt These are relevant settings that Travis uses: {{{ GhcStage2HcOpts += -DDEBUG DYNAMIC_GHC_PROGRAMS = NO GhcLibWays = v }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:21:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:21:06 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.2db4229192bf91f3b2cfc147fd17cd22@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): jscholl: very very helpful, thank you. With your nice small case I nailed the bug in 15 mins. Patch coming. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:32:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:32:26 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.a32027f77993e11c758a387381535746@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): All that you say is true about type function too. In {{{ type instance F a a = Int }}} the `a` is definitely not unused becuase it is repeated. In both your examples the type variables patently are used, and no one is suggesting they are reported as unused: {{{ instance C a a where ... instance D a b => C (a,b) where... }}} But it really does seem useful an convenient to be able to write {{{ type instance F (Maybe _) = Int }}} to stress that the argument to `Maybe` plays no further role in matching or on the RHS. Isn't it? Similarly would it not be reasonable to allow {{{ instance C (Maybe _) where ... }}} to stress that the argument type of the `Maybe` plays no further role in resolving this class instance. So let me be more concrete. Here's a proposal: * If a type variable (a) is bound in a type pattern (b) appears at exactly once anywhere in its scope, then it is reported as unused. * A "type pattern" is * a type on the LHS of a `type instance` or * a type in the head of a class `instance` (i.e. the bit after the `=>`) * a type in a pattern type signature e.g. `case x of Just (x :: (a,b)) -> blah` Now, can you give me an example where that would be annoying? Mabye you are right, but let's see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:33:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:33:33 -0000 Subject: [GHC] #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error Message-ID: <042.e058b949ddfb9ef1b73d598691d8a53f@haskell.org> #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- To document this bug, we're going to need a typechecker plugin to test it with. I've built a dummy plugin for this purpose, so we can be sure it is not interference from a particular plugin. {{{dummy-plugin/dummy-plugin.cabal}}} {{{ name: dummy-plugin version: 0.1.0.0 category: Development build-type: Simple cabal-version: >=1.10 library hs-source-dirs: . exposed-modules: DummyPlugin build-depends: base, ghc default-language: Haskell2010 GHC-options: -Wall -O2 }}} {{{dummy-plugin/DummyPlugin.hs}}} {{{#!hs module DummyPlugin(plugin) where import TcRnMonad ( TcPlugin(..), TcPluginResult(..) ) import Plugins ( defaultPlugin, Plugin(..), CommandLineOption ) plugin :: Plugin plugin = defaultPlugin { tcPlugin = Just . thePlugin } thePlugin :: [CommandLineOption] -> TcPlugin thePlugin opts = TcPlugin { tcPluginInit = return () , tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] [] , tcPluginStop = \_ -> return () } }}} {{{Bug.hs}}} {{{#!hs {-# OPTIONS_GHC -fplugin=DummyPlugin #-} module Bug where impossible :: a impossible = undefined }}} First, compile the dummy plugin. From its directory, run {{{cabal install}}} to install the plugin. Then, from the main directory, run {{{ghc Bug.hs}}}. Expected result: the file compiles. Actual result: {{{ Bug.hs:6:14: error: ? Unbound implicit parameter ?callStack::GHC.Stack.Types.CallStack arising from a use of implicit parameter ??callStack? ? In the expression: undefined In an equation for ?impossible?: impossible = undefined }}} Further, observe that commenting out the line which invokes the type- checker plugin (the pragma on line 1) causes the file to compile correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:33:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:33:35 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.5e23bd0ffc50281c13ca5a6624dac474@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab: D1802 -------------------------------------+------------------------------------- Changes (by niteria): * differential: phab:D1792 => phab:D1792, phab:D1801, phab: D1802 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:33:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:33:55 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.e7de93051a0af40a54be2dfbbae1d457@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Changes (by niteria): * differential: phab:D1792, phab:D1801, phab: D1802 => phab:D1792, phab:D1801, phab:D1802 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:49:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:49:20 -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.f1e029cef2a4ec27c25183856a983244@haskell.org> #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 thomie): * cc: gridaphobe (added) * priority: high => highest * version: 7.10.3 => 8.0.1-rc1 Comment: Thank you for reducing the problem to this simple testcase. This is a regression from ghc-7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 22:55:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 22:55:21 -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.700e627fc4e118ca7955409d145699ed@haskell.org> #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: gridaphobe Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 gridaphobe): * owner: => gridaphobe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 23:15:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 23:15:13 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.e480b24e29a152e91c247f613470944f@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): Omer writes: I found one of the problems with #11444, but I don't know how to fix it. The problem is that the desugarer is generating this function: {{{ ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Str=DmdType] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> == @ Int GHC.Classes.$fEqInt (case reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws of wild_00 { __DEFAULT -> GHC.Types.I# wild_00 }) (GHC.Types.I# 1#) } } }}} Which is lint-safe. Then, the optimizer is transforming this into: {{{ ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Arity=2, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 71 0}] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws)) (I# 1#) } } }}} The problem with this, according to the linter, is the argument of I# is not OK-for-speculation (the expression `reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws`). The reason is because arguments of `reallyUnsafePtrEquality#` are not OK-for-speculation, because their types are polymorphic, and variables with polymorphic types are not OK for speculation. However, I think this expression should be OK-for-speculation, because it can't fail, the primop is not out-of-line etc. I think all the requirements for being OK for speculation hold here. So my questions are: - Does that look like a correct optimization transformation? (it looked OK to me, but wanted to make sure) - Am I right that this expression should be OK for speculation? - What's a good way to make this code lint-safe? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 19 23:16:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jan 2016 23:16:48 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.aa2e79a260f05ca4ac98c8dc1568e52b@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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): But how does this lead to the `applyTypeToArgs` panic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 00:03:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 00:03:19 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.bd7355fa2eb44611b8310390730ea1a5@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by ekmett): > Now, can you give me an example where that would be annoying? Mabye you are right, but let's see. Let's look at what happens to a real instance list for a data type that I have open on my screen, the haddocks would then show the following instances and class associated types. {{{#!hs Category * (Indexed _i) (~) * i j => Indexable i (Indexed j) Arrow (Indexed _i) ArrowChoice (Indexed _i) ArrowApply (Indexed _i) ArrowLoop (Indexed _i) Representable (Indexed _i) Corepresentable (Indexed _i) Choice (Indexed _i) Closed (Indexed _i) Strong (Indexed _i) Costrong (Indexed _i) Profunctor (Indexed _i) Conjoined (Indexed _i) Bizarre (Indexed Int) Mafic Sieve (Indexed i) ((->) i) Cosieve (Indexed i) ((,) i) Sellable (Indexed i) (Molten i) Bizarre (Indexed i) (Molten i) Monad (Indexed _i _a) Functor (Indexed _i _a) MonadFix (Indexed _i _a) Applicative (Indexed _i _a) Apply (Indexed _i _a) Bind (Indexed _i _a) type Rep (Indexed i) = (->) i type Corep (Indexed i) = (,) i }}} It seems to me the vast majority of instances I have lying around would get almost all of their arguments mangled. Using that as an entirely unscientific survey, 19/27 or ~70% of those instances would have to have their code changed, to get uglier haddocks. Ramped up to cut across the ~10000 instances in my active maintenance directory instead of the 27 in this single source file, that would be annoying. =/ ''Allowing'' the use of _'s in those positions seems perfectly fine to me, but requiring it would create tension between being able to provide clean- looking haddocks and avoiding this warning, or doing something cheesy like writing unnecessary, brittle, `InstanceSigs`. Ultimately, no user of `MonadState` cares about the fact that `s` isn't used in the body of {{{#!hs instance MonadReader r m => MonadReader r (StateT _s m) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 00:03:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 00:03:48 -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.c9fea305e679e3f3b553fe4ea543a71b@haskell.org> #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: 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 gridaphobe): * status: new => patch * testcase: => T11462 * differential: => Phab:D1804 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 00:56:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 00:56:13 -0000 Subject: [GHC] #11437: Don't put static (version-based) feature gates in compilerInfo In-Reply-To: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> References: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> Message-ID: <060.c8faf8aacce032e776ad27628b9742db@haskell.org> #11437: Don't put static (version-based) feature gates in compilerInfo -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 thomie): > I think it's probably wrong for GHC to put feature gates in this structure which are always on or off Why? Why do you want to remove them? And which fields are you talking about specifically? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 00:59:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 00:59:46 -0000 Subject: [GHC] #11437: Don't put static (version-based) feature gates in compilerInfo In-Reply-To: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> References: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> Message-ID: <060.1805e820bef41209183429e6a45343e2@haskell.org> #11437: Don't put static (version-based) feature gates in compilerInfo -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 ezyang): The feature gates which I want to remove are `Support parallel --make`, `Support reexported-modules`, `Support thinning and renaming package flags`, `Requires unified installed package IDs` and `Uses package keys`. I want to remove these because, if this is followed to its logical extreme, you'll end up putting lots of feature gates in `compilerInfo`, ballooning its size, slowing down Cabal (since it always has to parse this structure when it is configuring). What should you put in this structure? If we want to continue feature-testing, we should do it another way, like giving a list of supported flags, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 01:28:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 01:28:40 -0000 Subject: [GHC] #11437: Don't put static (version-based) feature gates in compilerInfo In-Reply-To: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> References: <045.fac0a9079eb4a35d68263d2e57b96d35@haskell.org> Message-ID: <060.a7f88f3362845efc6bce889e9b2402c0@haskell.org> #11437: Don't put static (version-based) feature gates in compilerInfo -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 thomie): Ah, for some reason I was thinking about the `settings` file. Sure, if everything keeps working, remove 'em. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 01:50:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 01:50:12 -0000 Subject: [GHC] #1316: add warning for local type signatures that use the same type variable names as outer type signatures In-Reply-To: <051.fc0097e380c9c982131869ff2c172623@haskell.org> References: <051.fc0097e380c9c982131869ff2c172623@haskell.org> Message-ID: <066.e98951e00a0aa5e7e3c21051fdd7d6d3@haskell.org> #1316: add warning for local type signatures that use the same type variable names as outer type signatures -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11438 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11438 Comment: Closing as a duplicate of #9244, which has a more complete test case, and suggestions for how to implement this. Also reported as #11438. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 01:52:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 01:52:58 -0000 Subject: [GHC] #11438: Code does not compile without ScopedTypeVariables In-Reply-To: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> References: <050.64bb21b7a3b2bce43da5c03ab52be1f8@haskell.org> Message-ID: <065.eaacbe451b2044fb6cb9e112b49378fc@haskell.org> #11438: Code does not compile without ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #9244, | Differential Rev(s): #3691 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #1316, #9244, #3691 Comment: goldfire, hold that thought, but also subscribe to #9244. I'm closing this as a duplicate, so we can keep discussion in one place. #9244 has a nice test case (without dependencies), and some other suggestions for a better error message. wereHamster: thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 01:56:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 01:56:10 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.2b8c9142fb9484ae821f0341dce999ba@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1316, #3691, #11438 * milestone: => 8.2.1 Comment: Also reported as #1316, #3691, #11438 and maybe others. @goldfire writes in ticket:11438#comment:1 (I'm moving the discussion here): > An easy way of suggesting ScopedTypeVariables just came to mind: pretend the extension is always on. When looking up a type variable, if the extension is off but the variable would be in scope otherwise, suggest the extension, while returning a lookup failure (because the variable really isn't in scope!). Getting caught on ScopedTypeVariables is a fairly common occurrence in my experience, so I think it's worth putting in a bit of effort to do better here. (Even better would be to look for type variables in a signature that's missing a forall to suggest adding the forall, but that can be a separate task.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 02:03:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 02:03:39 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.d45785b41f3235c8a1c441df433b11f2@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438,10581 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #1316, #3691, #11438 => #1316, #3691, #11438,10581 Comment: @goldfire in #10581: > The ScopedTypeVariables extension is one of the few that doesn't recommend itself when it should be used. > > I recognize that this may be hard to do, but here is a strawman proposal: Always behave as if ScopedTypeVariables is on at binding sites for type variables (in an annotation with forall). Then, at occurrences of type variables, check if the extension is on. If a type variable is in scope but the extension is off, remember that the user probably wants the extension, but then rename the type variable occurrence away from the in- scope one. If a type error ensues, we've remembered that the lack of ScopedTypeVariables may be to blame, and we recommend turning it on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 02:04:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 02:04:04 -0000 Subject: [GHC] #10581: Recommend ScopedTypeVariables In-Reply-To: <047.ebee173d1dfb8530d61c89de5afef934@haskell.org> References: <047.ebee173d1dfb8530d61c89de5afef934@haskell.org> Message-ID: <062.b14585ba89f56cefdda8e5a857b9f53e@haskell.org> #10581: Recommend ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9244 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9244 Comment: Closing this one as a duplicate of #9244 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 02:13:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 02:13:59 -0000 Subject: [GHC] #11440: GHC.Prim does not export Constraint In-Reply-To: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> References: <045.ac124f420503b21143d33cecc1fab7bd@haskell.org> Message-ID: <060.15cfa7876541c075e61945727efe4f8f@haskell.org> #11440: GHC.Prim does not export Constraint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie): Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 02:16:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 02:16:14 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.1664ef6270134db4287db5c8ba059f6e@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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 thomie): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 02:22:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 02:22:31 -0000 Subject: [GHC] #11448: New --frontend mode is only partially documented In-Reply-To: <045.498508dda538a30f2c57476495771712@haskell.org> References: <045.498508dda538a30f2c57476495771712@haskell.org> Message-ID: <060.886aef41295f342692f231e2ab84ad36@haskell.org> #11448: New --frontend mode is only partially documented -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1793 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 04:52:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 04:52:54 -0000 Subject: [GHC] #11463: Template Haskell applies too many arguments to kind synonym Message-ID: <050.c7d753a5f21fb330e97bd8d6b7fe7cde@haskell.org> #11463: Template Haskell applies too many arguments to kind synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc1 Haskell | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11376 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running the following code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} module IdStarK where import Data.Kind import Language.Haskell.TH type Id a = a data Proxy (a :: Id k) = Proxy $(return []) main :: IO () main = do putStrLn $(reify ''Proxy >>= stringE . pprint) putStrLn $(reify ''Proxy >>= stringE . show) }}} Gives a result I wouldn't have expected: {{{ $ /opt/ghc/head/bin/runghc IdStarK.hs data IdStarK.Proxy (a_0 :: IdStarK.Id * k_1) = IdStarK.Proxy TyConI (DataD [] IdStarK.Proxy [KindedTV a_1627394516 (AppT (AppT (ConT IdStarK.Id) StarT) (VarT k_1627394515))] Nothing [NormalC IdStarK.Proxy []] []) }}} From the output, it appears that `Id` is being applied to ''two'' arguments, both `*` and `k`! Perhaps this indirectly (or directly) a consequence of #11376? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 05:49:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 05:49:08 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.e0e774c543ede03df4c07dba43dc6c1e@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748 -------------------------------------+------------------------------------- Comment (by Phyx-): I have it working on Windows now. Will clean it up and put it for review soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 06:00:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 06:00:16 -0000 Subject: [GHC] #11223: Runtime linker performs eager loading of all object files In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.dda3703bf1e4601f5cceb25bdbc73df0@haskell.org> #11223: Runtime linker performs eager loading of all object files -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 #11317 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => * related: #10726 => #10726 #11317 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 06:16:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 06:16:21 -0000 Subject: [GHC] #11223: Runtime linker performs eager loading of all object files In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.a4fb8cba5c40aeadb6f71340220722cb@haskell.org> #11223: Runtime linker performs eager loading of all object files -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 #11317 | Differential Rev(s): Phab:D1805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * differential: => Phab:D1805 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 06:16:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 06:16:32 -0000 Subject: [GHC] #11223: Runtime linker performs eager loading of all object files In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.402fd2125b945d2bf0152c9b1316a8df@haskell.org> #11223: Runtime linker performs eager loading of all object files -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 #11317 | Differential Rev(s): Phab:D1805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 08:10:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 08:10:22 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.75c57812d0bb1f65ac9817c3841c3f94@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 Simon Peyton Jones ): In [changeset:"514bac264cb60db26ff9da10c6b79c3f5bd6e96d/ghc" 514bac2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="514bac264cb60db26ff9da10c6b79c3f5bd6e96d" Fix combineIdenticalAlts This long-standing bug in CoreUtils.combineIdenticalAlts was shown up by Trac #11172. The effect was that it returned a correct set of alternatives, but a bogus set of "impossible default constructors". That meant that we subsequently removed all the alternatives from a case, and hence ended up with a bogusly empty case that should not have been empty. See Note [Care with impossible-constructors when combining alternatives] in CoreUtils. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 08:23:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 08:23:44 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.274d94852fc10560c50a63ea8894931e@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: 9218 | Blocking: Related Tickets: #9218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hmm these functions are marked deprecated on MSDN. The recommendation is to use the C++ ISO conforming version of these POSIX calls https://msdn.microsoft.com/en-us/library/ms235454.aspx which always includes the _ in the names. Even when using cdecl. Is this ticket still an issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 08:24:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 08:24:13 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.ebe735741bc1f34d0a1a287b28be15a9@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: 9218 | Blocking: Related Tickets: #9218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:06:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:06:32 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.688482b49df579062bc4d72183f189c2@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: 9218 | Blocking: Related Tickets: #9218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Some projects have changed their code: {{{ #if _WIN64 #define STRDUP _strdup #else #define STRDUP strdup #endif }}} * https://github.com/snoyberg/yaml/pull/45 * https://github.com/bsl/bindings- GLFW/commit/86271bcff4897c1c563af0058111705111d1ba7e We should probably not add any special cases to the linker (it's complicated enough already!) to effectively un-deprecate those functions. It is still rather unfortunate that those ifdefs are unnecessary though. @snoyberg might have an opinion, since he mentioned in https://github.com/snoyberg/yaml/issues/44#issuecomment-46459264: "There's no good reason why C code being compiled by GHC should need to be modified to avoid using strdup, that's certainly a bug in the toolchain, not the code." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:13:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:13:31 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.4811b4e94998e3744783cbc97cbe1216@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by thomie): Some of the following `validate --slow` failures are probably also caused by this patch: https://phabricator.haskell.org/D1652#53187 To reproduce, in `testsuite/tests`, run: `make TEST="conc014 T3279 conc012 print029 print025 print022 print006 print005 print003 print008 break018 T2740 hist001 break017 break010 break011 break012 dynbrk002 print032 print030 print031 print010 print018 print019 break027 break026 break021 break020 break009 break006 break005 break003 break028 break001 result001 tcrun028 T8119 T7653 exceptionsrun001 break022 tc180 T4969 tc152 tc187 tc126 tc125 Vta1 Vta2 overloadedlabelsghci01 T11351 T3023 tcfail093 T10728 T7332 T6015 T11248 T6015a T6068 VtaParse dynamic-paper haddock.Cabal" CLEANUP=1 slow` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:29:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:29:31 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.d1667ad7dd1caf56b3c687d86ac92a1a@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 Simon Peyton Jones ): In [changeset:"0373a8458a9d5ed0732d06ffd082b939c11b6adc/ghc" 0373a84/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0373a8458a9d5ed0732d06ffd082b939c11b6adc" Oops. Add missing close-comment This fixes 514bac2 for Trac #11172. Sorry! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:31:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:31:24 -0000 Subject: [GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling In-Reply-To: <045.6104ef63780cb1088603ac8080468c98@haskell.org> References: <045.6104ef63780cb1088603ac8080468c98@haskell.org> Message-ID: <060.f21dc0e0cfceebb90d11ac23ea4df2c2@haskell.org> #11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Template Haskell | Version: 7.11 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 also [https://mail.haskell.org/pipermail/ghc- devs/2016-January/011064.html this thread on "Host-Oriented Template Haskell"] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:37:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:37:06 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.38e03c76a8d1096d647403873bf65a78@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Lemming): For me the warning could be as pedantic as Simon suggests, if it is not part of -Wall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:44:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:44:07 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.7d68cbb1dcdcf9c128d06ef70ed10514@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): What I'm missing is this: why would it not be more perspicuous to say {{{ Category * (Indexed _) }}} That doesn't look like mangling to me. It looks like explaining that `Indexed` of anything is an instance. Similarly {{{ instance MonadReader r m => MonadReader r (StateT _ m) }}} Is that bad? If it is, why do you not object to the warning you get (for unused `y`) when you write this? {{{ f x y = x }}} I'm not arguing against you, just trying to understand. Are you also saying that you do not like {{{ type instance F (Maybe _) = Int }}} and that you want to be able to write {{{ type instance F (Maybe x) = Int }}} without a warning? That is, do you see class instances and type-function instances the same? It would be easier NOT to issue warnings. But if we do sometimes and not at other similar-looking times, I'd like to have a principled explanation. Can you give a general rule that informs your choices? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 09:57:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 09:57:25 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.2cfcf33429008952eaff804e91225a85@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: 9218 | Blocking: Related Tickets: #9218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I have just removed all the special cases from the linker in Phab:D1805 which means GHCi will *probably* not load this library anymore either... If it ever did.. I also think that their patch only fixes 64bit compilation but not 32bit. The prefixed _ has nothing to do with the usual name mangling of functions. Instead it was a conscious choice by Microsoft to deprecate the functions that are not part of the C standard (`strdup` is `POSIX`, not `C`, and the Microsoft POSIX Subsystem was never fully POSIX compliant afaik, SUA was but that's now deprecated.) into a different namespace following the C++ ISO naming convention. https://msdn.microsoft.com/en- us/subscriptions/7e259932-c6c8-4c1a-9637-639e591681a5(v=vs.90) in order to free up the namespace to user defined functions. As in, on Windows `strdup` should always be used as `_strdup` regardless if it's 32 or 64bit. And indeed, if you look at the export table of the standard C runtime on Windows (msvcrt) which both GHCi and MingW-w64 link to: {{{ >dumpbin /exports c:\Windows\SysWOW64\msvcrt.dll | findstr "strdup" 859 35A 000247AD _strdup 860 35B 000801D6 _strdup_dbg >dumpbin /exports c:\Windows\System32\msvcrt.dll | findstr "strdup" 742 2E5 000152D0 _strdup 743 2E6 0006635C _strdup_dbg }}} Both the 32bit and the 64bit version report only the undeprecated function, always with the _ prefix. So this is not a GHC bug, nor a Windows one. The library just did not use the correct function as stated on MSDN. The correct fix would probably be {{{ #if _WIN32 #define STRDUP _strdup #else #define STRDUP strdup #endif }}} Because it will always be the case on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 10:33:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 10:33:41 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.77621250297286409cda4b4559478b4b@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): OK thanks to jscholl the bug is fixed. But I am still eager to know why this could give a **seg-fault**. An "impossible alternative" message perhaps; but a seg-fault is more worrying. Ben describes how to elicit the seg-fault in comment:17. (NB: you need the `segfault` branch of his repo.) jscholl: if you could repeat your amazing work on this variant, to make a much smaller seg-faulting test case, that would be amazing. (Of course it is always possible that there are two bugs, and I have only fixed one; another reason to investigate the seg-fault variant.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 11:57:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 11:57:35 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.dacea8d9997d8b70058a483b219142ea@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We appear to be on to Phab:D1774 now, correct? Change the Phab link? Like Richard I'm getting lost. That Phab seems to be spiraling out of control. Let's take one thing at at time. * Is `Proxy Char#` a valid type? Not currently: we get {{{ Illegal unlifted type: Char# }}} But there is no reason for this to be rejected! `Proxy :: forall k. k ->*`, and I see no reason why we can't instantiate `k` with `TYPE Unlifted`. Looking further, the error message comes not from the kind- unifier, but later in `TcValidity`; see `check_lifted`. I think we can probably simply remove all calls to `check_lifted`. * Can you have `TypeRep Char#` or `typeRep @Char#`, or `Typeable Char#`. Again, you can't right now, but actually I think you could; they are all kind-polymorphic, and the instantiating kind could be `TYPE Unlifted`. * If we did, we might be faced with solving `Typeable Char#`. That would mean adding a type rep for `Char#`; but we could simply make it insoluble for now, and report a type error. * Could solving `Typeable Char#` come up in GHC today (i.e. without fixing `TcValidity`)? Yes: consider `typeRep (undefined :: Proxy (Char# -> Int)`. Nothing wrong with that on the face of it. So we generate `Typeable (Char# -> Int)` constraint, and then decompose to `Typeable Char#` and `Typeable Int`. And then we fail in solving `Typeable Char#` * What about ''promoted'' data constructors? {{{ data CH = DCH Char# }}} Now suppose (comment:14) that we ask for `typeOf (Proxy :: Proxy 'DCH)`. This gives `Typeable 'DCH`. At the moment I can't see why that would need a type-rep for `Char#` as comment:14 suggests. Any ideas? So my proposal is: * Let's NOT (yet) have type-reps for primitive types * Let's fix the Typeable solver so that it fails gracefully on `Typeable Char#`. * And let's try the effect of removing the `check_unlifted` in `TcValidity`. Would that be a good start? That still leaves open the questions in comment:3. But first things first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 12:18:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 12:18:19 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.84019cc31cd61a69710f54f8309e471d@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by ekmett): > What I'm missing is this: why would it not be more perspicuous to say {{{#!hs Category * (Indexed _) }}} So that in 3-4 years when I can stop supporting older compilers, I can finally lose the signaling of intent that comes from the conventions that we follow elsewhere of `f` and `m` and `a`? There is a lot of information packed in those conventions. Nobody reading the documentation cares whether the instance uses the argument or not, but this warning would force everyone to put that front and center in the documentation users see and seems to clutter about 70% of the variables in instances out there with a perl-like `_` sigil. I like having names for things rather than Miranda's `*`, `**`, `***`. That said, one of the biggest sources of teasing from the outside world about haskell is how short our type variable names tend to be, getting rid of them entirely like this ''is'' one way to avoid the argument. ;) > If it is, why do you not object to the warning you get (for unused y) when you write this? {{{#!hs f x y = x }}} Nothing we do at the value level is reflected in the documentation; everything we do at the type level is reflected in the documentation. The fact that the value-level unused binding warning is on or not is invisible to the user of the library. Whether I turn on the warning about unused bindings at the value level or not the user never sees this fact. It remains entirely internal to the source file as a local concern. > That is, do you see class instances and type-function instances the same? Going from the current state where ''can't'' use `_` in that position at all, to a new state where you ''must'' use `_` or `_a` in a place that affects generated documentation and affects the vast majority of instances that have ever been written seems like a big jump, when the existing style has been in use for 20+ years. This seems to indicate to me that doing this to instances is quite a big deal and the amount of work for the user community boggles my mind. As for type instances, this then hoists you on the dilemma of copying the value level warning style or matching the behavior of instances. The resolution you seem to be reaching for is to change the behavior of instances to match, and it would cleanly resolve the dilemma, but at a rather great cost. In many ways the same "it shows up in the documentation" argument applies to the `type instance` case as well, now that haddock actually shows type families, but there is a lot less code affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 12:37:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 12:37:53 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.b73d6be2d3ba81a984b11ffb82d1e2f2@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D1769 => Phab:D1774 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 12:53:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 12:53:39 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.2fe886052d8169f34193aa701c2f2d86@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Like Richard I'm getting lost. That Phab seems to be spiraling out of control. Let's take one thing at at time. Indeed, that is my fault for conflating several concerns. The situation isn't as complex as it appears. To recap, * Phab:D1774 is primarily a refactoring of how we produce representations for types that were previously handled explicitly in `Data.Typeable.Internal`. In particular, instead of writing them by hand we now lead their production to the compiler. This is a significant simplification from the previous scheme as its almost entirely consistent with the codepath used for user-defined types. * This new approach also allows us to trivially produce representations for the primitive types in `GHC.Prim` without the boiler-plate required previously. * All of the above currently works. * The kind representation work is quite unrelated to the Phab:D1774 (although perhaps made easier by it) * I have also not touched the `TcValidity` check although was asking about it on the Diff, which caused a bit of confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 13:07:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 13:07:00 -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.d60b37e9f64f040d480611638d21dab1@haskell.org> #11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: plugin 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): Indeed, rejecting potentially-solvable constraints would be a bit tricky to do accurately, because of the intertwining of different kinds of constraint solving. It should be easy to run the plugins first and permit them to reject dictionary constraints that have arisen directly from the source, but it's not clear that is very useful because many constraints arise during solving. (Moreover, this would not work for equality constraints, because those are handled eagerly by the unifier.) I suppose one could imagine an alternative architecture for plugins that gave them each new constraint as GHC generated it, which would be capable of doing this, but would be much more deeply tied into GHC's constraint- solving algorithm. Another possibility we've considered in the past is making it possible for a plugin to replace GHC's entire constraint solver pipeline. That could be interesting from the point of view of experimenting with alternative constraint-solving algorithms, but I'm not sure how feasible it is. For this specific feature request, I suspect it would be easier to do it inside GHC itself, by checking for suppression pragmas during instance lookup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 13:12:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 13:12:37 -0000 Subject: [GHC] #9525: +RTS -xc stack trace sometimes reported twice In-Reply-To: <043.b89cf286c7ba7d4a16178fcdcd90d766@haskell.org> References: <043.b89cf286c7ba7d4a16178fcdcd90d766@haskell.org> Message-ID: <058.3c98080fca6371152113bb711a6bac33@haskell.org> #9525: +RTS -xc stack trace sometimes reported twice -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: profiling, | stack trace, error Operating System: Unknown/Multiple | 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 thomie): * priority: low => normal * component: Runtime System => Profiling Comment: Some duplicates stack traces in this output as well, with a profiled `ghc`: http://lpaste.net/1842576927450202112. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 13:55:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 13:55:52 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.7c3043d3dc167cfc0793d6d7ecadb817@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): So the principle you are suggesting is that if it shows up in documentation you do not want to have a warning for unused variables. That's a fine principle; I just want to articulate it clearly. If so we should ensure that {{{ type instance F (Maybe a) = Int }}} does not give a warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 14:17:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 14:17:35 -0000 Subject: [GHC] #11464: Type casts cause confusing error Message-ID: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> #11464: Type casts cause confusing error -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Try this {{{ instance Eq (Either a) }}} GHC HEAD gives {{{ Foo.hs:9:10: error: ? Illegal instance declaration for ?Eq (Either a)? (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) ? In the instance declaration for ?Eq (Either a)? Foo.hs:9:14: error: ? Expecting one more argument to ?Either a? Expected a type, but ?Either a? has kind ?* -> *? ? In the first argument of ?Eq?, namely ?Either a? In the instance declaration for ?Eq (Either a)? }}} The second is right but the first is outright misleading. Reason: we elaborate to {{{ Eq (Either a |> g) }}} where `g` is a type-level kind cast; it's insoluble and gives rise to the second error. But the elaborated type confuses `checkValidInstHead`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 14:34:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 14:34:01 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.ada9beb2814b74d3ea26d8ce4d64a1ea@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): I've just run `make TEST="conc014 T3279 conc012 print029 print025 print022 print006 print005 print003 print008 break018 T2740 hist001 break017 break010 break011 break012 dynbrk002 print032 print030 print031 print010 print018 print019 break027 break026 break021 break020 break009 break006 break005 break003 break028 break001 result001 tcrun028 T8119 T7653 exceptionsrun001 break022 tc180 T4969 tc152 tc187 tc126 tc125 Vta1 Vta2 overloadedlabelsghci01 T11351 T3023 tcfail093 T10728 T7332 T6015 T11248 T6015a T6068 VtaParse dynamic-paper haddock.Cabal" CLEANUP=1 slow` on `80265c4c3c827695e92dd9620faf47e064b5da37` a revision right before my commit and it's failing with this: {{{ Unexpected results from: TEST="conc014 T3279 conc012 exceptionsrun001 T11351 Vta1 Vta2 T10728 T11248 VtaParse dynamic-paper" OVERALL SUMMARY for test run started at Wed Jan 20 06:16:25 2016 PST 0:03:42 spent to go through 61 total tests, which gave rise to 137 test cases, of which 2 were skipped 1 had missing libraries 111 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 23 unexpected failures 0 unexpected stat failures Unexpected failures: ../../libraries/base/tests exceptionsrun001 [bad exit code] (hpc) concurrent/should_run T3279 [bad exit code] (hpc,optasm,threaded2,dyn) concurrent/should_run conc012 [bad exit code] (hpc,optasm,threaded2,dyn) concurrent/should_run conc014 [bad stdout] (hpc,optasm,threaded2,dyn) dependent/should_compile dynamic-paper [exit code non-0] (hpc,optasm) parser/should_compile VtaParse [exit code non-0] (hpc) patsyn/should_compile T11351 [exit code non-0] (hpc) polykinds T11248 [exit code non-0] (hpc,optasm) rts T10728 [bad stdout] (threaded2) rts T10728 [bad stdout or stderr] (ghci) typecheck/should_compile Vta1 [exit code non-0] (hpc) typecheck/should_compile Vta2 [exit code non-0] (hpc) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 14:51:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 14:51:20 -0000 Subject: [GHC] #11463: Template Haskell applies too many arguments to kind synonym In-Reply-To: <050.c7d753a5f21fb330e97bd8d6b7fe7cde@haskell.org> References: <050.c7d753a5f21fb330e97bd8d6b7fe7cde@haskell.org> Message-ID: <065.609051c5a965ca1d40a44c8b9f0eb34d@haskell.org> #11463: Template Haskell applies too many arguments to kind synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType 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 goldfire): * keywords: TypeInType, TypeApplications => TypeInType * related: #11376 => Comment: No -- this is not #11376. I'll put this in my queue. My guess is that we just need a `filterInvisibles` somewhere in !TcSplice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 15:00:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 15:00:12 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.1733dca2bb74804b5ef8b0c2674e2171@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Fully agreed with all points in comment:19. And, in response to comment:21, the !TcValidity check is not new. But, as Simon suggests, it may have outlived its usefulness. Does it date back to some point in prehistory when the kind system didn't distinguish `*` from `#`? It seems like it to me (though I haven't actually looked through the history). In any case, let's resolve type representations on this ticket by either getting representation for `Char#` and the like, or gracefully erroring. (I prefer the latter, given the date.) Then we can post a new ticket to look into the !TcValidity issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 15:05:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 15:05:50 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity Message-ID: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- In `TcValidity`, when checking for valid types, we had a long-standing test, embodied in a local function called `check_lifted`, which checked that a number of places had a lifted type of kind `*` and not an unlifted one of kind `#`. But that test is out-dated now; the kind system does the job. So this ticket is to remove the `check_lifted` test. See the discussion in #11120, starting at comment:19. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 15:31:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 15:31:33 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter Message-ID: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- This: {{{ {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module Foo where type Foo = ?foo::() }}} gives {{{ Foo.hs:3:1: error: ? Illegal implicit parameter ??foo::()? ? In the type synonym declaration for ?Foo? }}} in GHC HEAD. It used to work in GHC-7.10. Did not check GHC-8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:02:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:02:25 -0000 Subject: [GHC] #11467: Panic while type checking expression using function with context holes Message-ID: <048.6a7d6765f60a755d0914f8061e991d71@haskell.org> #11467: Panic while type checking expression using function with context holes -------------------------------------+------------------------------------- Reporter: HairyDude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs module Bug where holey :: _ => _ holey = undefined useHoley = holey True }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:3:10: Found hole ?_? with inferred constraints: () To use the inferred type, enable PartialTypeSignatures In the type signature for ?holey?: _ => _ Bug.hs:3:15: Found hole ?_? with type: w_1 Where: ?w_1? is a rigid type variable bound by the inferred type of holey :: w_1 at Bug.hs:4:1 To use the inferred type, enable PartialTypeSignatures In the type signature for ?holey?: _ => _ Bug.hs:6:12: Couldn't match expected type ?Bool -> t0? with actual type ?w_? ?w_? is untouchable inside the constraints () bound by the inferred type of useHoley :: t0 at Bug.hs:6:1-21ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): No skolem info: w__alO[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:03:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:03:50 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.76bb436b02c4068c9591cdf7bdf43d13@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by ekmett): I think that adopting that principle would work and neatly encodes existing practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:07:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:07:09 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.00d0c22953a0df7ac21d928d8d6c69aa@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1797 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5cce09543db827e662539523ffff4513deb92777/ghc" 5cce0954/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5cce09543db827e662539523ffff4513deb92777" Use (&&) instead of `if` in Ix derivation We were previously using `if` in the derivation of `Ix` instances. This interacts badly with RebindableSyntax as the typechecker doesn't infer the type of the argument we give to `tagToEnum#`. Previously we produced, `if (ch >= ah) then (ch <= bh) else False`. We now produce `(ch >= ah) && (ch <= bh)` Fixes #11396. Test Plan: Validate Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1797 GHC Trac Issues: #11396 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:07:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:07:09 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.d08dee6e5519e57a835d90d234dc448c@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"84b0ebedd09fcfbda8efd7576dce9f52a2b6e6ca/ghc" 84b0ebe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="84b0ebedd09fcfbda8efd7576dce9f52a2b6e6ca" Rework derivation of type representations for wired-in things Previously types defined by `GHC.Types` and `GHC.Prim` had their `Typeable` representations manually defined in `GHC.Typeable.Internals`. This was terrible, resulting in a great deal of boilerplate and a number of bugs due to missing or inconsistent representations (see #11120). Here we take a different tack, initially proposed by Richard Eisenberg: We wire-in the `Module`, `TrName`, and `TyCon` types, allowing them to be used in `GHC.Types`. We then allow the usual type representation generation logic to handle this module. `GHC.Prim`, on the other hand, is a bit tricky as it has no object code of its own. To handle this we instead place the type representations for the types defined here in `GHC.Types`. On the whole this eliminates several special-cases as well as a fair amount of boilerplate from hand-written representations. Moreover, we get full coverage of primitive types for free. Test Plan: Validate Reviewers: goldfire, simonpj, austin, hvr Subscribers: goldfire, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1774 GHC Trac Issues: #11120 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:09:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:09:59 -0000 Subject: [GHC] #11467: Panic while type checking expression using function with context holes In-Reply-To: <048.6a7d6765f60a755d0914f8061e991d71@haskell.org> References: <048.6a7d6765f60a755d0914f8061e991d71@haskell.org> Message-ID: <063.f689163f0f926090c428fedb283c0aa0@haskell.org> #11467: Panic while type checking expression using function with context holes -------------------------------------+------------------------------------- Reporter: HairyDude | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thanks. Happily, this works in HEAD and hence in 8.0. There are MANY bugs in partial type sigs in 7.10, which we won't fix. So I'll close this as fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:21:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:21:19 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.c94711dca587a0a083c1f7a1026ce1e0@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The TcValidity issue is now being tracked on #11465. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:22:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:22:03 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.c40c798d785ad095898e399d70069d70@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:44:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:44:43 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.dcd91eef99cf78390fd31eb1a3c4ab0f@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"225afc4ace4dff4ae52ac2147942cdeeb76fc723/ghc" 225afc4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="225afc4ace4dff4ae52ac2147942cdeeb76fc723" Add test T9407 (Windows) Add test for #9407. The test is only run on Windows 64bit, as this is where the problem occurred. Reviewed by: thomie Differential Revision: https://phabricator.haskell.org/D1806 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 16:53:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 16:53:42 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.bf2f0e5e79fda635ac16c141b48565a6@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | numeric/should_run/T9407 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => numeric/should_run/T9407 * resolution: => fixed Comment: Replying to [comment:7 rdragon]: > It looks like this issue has been fixed in GHC 7.10.2 or before. I can reproduce the problem with GHC 7.8.3, but not with 7.10.2. In both cases I use the 64-bit version. Since bisecting pre-7.10 commit ranges is rather difficult, I say we leave it at this. Let's hope it's really fixed! If someone really wants to investigate further, they can of course do so, and reopen this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 17:22:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 17:22:55 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.a469a07ceb3b87e2305b0601fadc3ce0@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 17:32:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 17:32:33 -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.88c6d8b1ef738b1b370a7a903728614c@haskell.org> #11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: plugin 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 gridaphobe): Replying to [comment:2 adamgundry]: > It should be easy to run the plugins first and permit them to reject dictionary constraints that have arisen directly from the source, but it's not clear that is very useful because many constraints arise during solving. Shouldn't plugins get access to the extra constraints as part of the inner loop in `solveSimpleWanteds`? Oh I see, `solveSimples` has its own loop that greedily solves the constraints that it can, bummer.. We could change `solveSimples` to not grab constraints from the work-list directly, but to just solve the constraints it's given. Then any new work- list items would have to go through the whole pipeline, including plugins. I don't know what the performance implications would be though. But even then, it would still be hard to ensure that our plugin gets to reject the dictionary constraint, what if another plugin runs first and solves it? Hrm.. > (Moreover, this would not work for equality constraints, because those are handled eagerly by the unifier.) Right, but to be fair, I can't think of a reason I, as a user, would want to reject an equality constraint that can be proven. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 17:51:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 17:51:36 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.3484c8ef4dae305d2cc024b3d9594cbe@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1807 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 18:01:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 18:01:22 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.857ce40d9e62c5bb792bc70bb9503bfe@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Things seem to work about as one would expect with Phab:D1807. However, this error could use a bit of work, {{{ ?> :set -XTypeInType -XDataKinds -XKindSignatures -XMagicHash ?> import GHC.Exts ?> class Eq Char# where (==) = undefined :3:10: error: Unexpected type ?Char#? In the class declaration for ?Eq? A class declaration should have form class Eq a where ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 19:09:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 19:09:53 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.3e98413f0cfd5ce311b33ad9ec448a38@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: 9218 | Blocking: Related Tickets: #9218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Alright, sounds convincing to me. Let's close this. > I have just removed all the special cases from the linker in ?Phab:D1805 Maybe you want to add something to the [wiki:Migration/8.0 migration guide] on that, or to the release notes maybe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 19:15:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 19:15:39 -0000 Subject: [GHC] #9214: UNPACK support for sum types In-Reply-To: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> References: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> Message-ID: <062.e15cef6c38f4f670d180a98551c4dffc@haskell.org> #9214: UNPACK support for sum types -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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:D1540 Wiki Page: UnpackedSumTypes | Phab:D1559 -------------------------------------+------------------------------------- Changes (by thomie): * owner: => osa1 * differential: => Phab:D1540 Phab:D1559 * wikipage: => UnpackedSumTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 19:25:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 19:25:24 -0000 Subject: [GHC] #9202: Strange Closure Type In-Reply-To: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> References: <049.264d997b4ade7d47b3d2c8df208015c7@haskell.org> Message-ID: <064.22661f98a08164bb1a6464511d2c9540@haskell.org> #9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: strange- | closure-type Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: This is an old bug reported against ghc-7.8.2 about "strange closure types" when installing `yesod-platform`. A lot has changed since then. I'm assuming this is fixed. If you do encounter it again, please open a new bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 20:09:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 20:09:43 -0000 Subject: [GHC] #11461: Allow pattern synonyms to be bundled with type classes? In-Reply-To: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> References: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> Message-ID: <064.5e4061e29c284ddb4cfb0f51aa3c9ce2@haskell.org> #11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | PatternSynonyms 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 hvr: @@ -11,1 +11,1 @@ - {{{ + {{{#!hs New description: One can very nearly get associated pattern synonyms by defining suitably polymorphic pattern synonyms. However, they are not quite associated as there's no way to bundle them with the class. This isn't as good as "proper" support but it would be an easy thing to implement for now if people think it worthwhile. For a concrete example, `Null` is an associated pattern synonym in this style but the following program doesn't compile because it is disallowed to bundle a pattern synonym with a type class. {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo(Nullable(Null)) where import Data.Maybe class Nullable f where null :: f a -> Bool instance Nullable (Maybe a) where null = isNothing pattern Null :: Nullable f => f a pattern Null = (null -> True) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 20:13:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 20:13:24 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.c985dd88db42f118679f693406db19f2@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually I have a patch ready to go... will commit tomorrow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 20:29:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 20:29:48 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.d014f6338eae2400ebf965cb1734b88f@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): * Attachment "Segfault.tar.gz" added. Smaller example triggering the segfault. Does not typecheck with 8.0-rc1... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 20:29:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 20:29:54 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.bb42fc87266558c744f6afa5508e599a@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): Ok, I think the segfault boils down to: Somewhere something expects to only recieve a {{{Right}}} constructor and then gets passed a {{{Left}}}. Hence the pointer is tagged with a 1 but should be tagged with a 2, we add 6 to access the contents and read the wrong memory. I think this could be related to the previous bug (only that this time the simplifier removes the impossible case alternative, so we do not enter an exception but this segfault in the case). To test this I first tried to run the example with ghc-8.0-rc1, but somehow it does not typecheck... I just get {{{ [1 of 2] Compiling Module ( Module.hs, Module.o ) Module.hs:28:38: error: ? Couldn't match kind ?GHC.Prim.Any? with ?*? When matching the kind of ?Either [Char]? ? In the third argument of ?runParser?, namely ?onError? In the expression: runParser (m v) [] onError Right In an equation for ?parseEither?: parseEither m v = runParser (m v) [] onError Right where onError _ = Left "Error in " }}} ghc-7.10.3 works fine, though. So maybe this is another regression? I just though the fix would work best with a current ghc. Anyway, here's the code. It's not as short as last time, sadly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 20:30:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 20:30:01 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.f96997ed5ddd0dd640946ee141c1e605@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"48d4bc53c517d5e2ac3ff734a7d7a0e2d9454717/ghc" 48d4bc5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48d4bc53c517d5e2ac3ff734a7d7a0e2d9454717" substTy to substTyUnchecked to fix Travis build This fixes the immediate problem from https://s3.amazonaws.com/archive.travis-ci.org/jobs/103319396/log.txt Test Plan: ./validate Reviewers: bgamari, austin, thomie Differential Revision: https://phabricator.haskell.org/D1802 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 21:09:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 21:09:14 -0000 Subject: [GHC] #9182: Empty case analysis for function clauses In-Reply-To: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> References: <046.2b1b9f70625d24c57bb7f92b03a8aab4@haskell.org> Message-ID: <061.e450b652f8558915366ca67c8daaefba@haskell.org> #9182: Empty case analysis for function clauses -------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11390 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #11390 Comment: A somewhat similar discussion took place in #11390. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 21:40:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 21:40:39 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.5be41e9aa6ea92aba84796816bde9ca5@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): I tried the fix with ghc-7.10.3 and the segfault vanished. If I compare the core it is almost identical, the only difference is that the fixed version generates a {{{Left}}} and a {{{Right}}} branch in Main.main3 while without the fix the {{{Left}}} branch is missing. So I think the segfault is really just another instance of the bug in the simplifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 21:46:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 21:46:57 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.68a7cfbd1a359502871495277a9c5e84@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): So it works with 7.10.3 and 8.0 rc1. So in which version does it seg- fault? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 22:14:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 22:14:19 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.9ae26437b0770fd693ad09d4984100c8@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): It only works when I manually include the important bits of 514bac2/ghc, otherwise it seg-faults. So the only working version right now should be HEAD as the fix dos not seem to be included any other branch yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 22:33:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 22:33:39 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.bf85bf1d02943ca10d97ba7e14a85b51@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 22:51:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 22:51:44 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.c6f59ca83b1eb1af3436fcd0a1b2a83d@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): I think I misunderstood. I think you are saying that it segfaults with an un-modified 7.10.3. That's fine; I can investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 23:04:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 23:04:26 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.2403f3daa7ce3eaf747c1b547795ebf4@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 thomie): To be clear: I'm not against this feature. Good error messages are important. I just think you should get some more feedback from others before spending time on implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 23:09:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 23:09:04 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.e673fccb0eff9b1008d07db6a7f588a1@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: closed => new * resolution: fixed => Comment: Issue still persists in -HEAD. I think it manifests better with unfixed warnings. Another stab at it: https://phabricator.haskell.org/D1809 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 23:09:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 23:09:26 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.de3dfc5fef8249368a8f201061c34caa@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1809 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D1809 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 20 23:22:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jan 2016 23:22:21 -0000 Subject: [GHC] #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input In-Reply-To: <045.aefffb38475deae13a93b03d7772087f@haskell.org> References: <045.aefffb38475deae13a93b03d7772087f@haskell.org> Message-ID: <060.6e8ad25445ba9893fb26e890365bfa0a@haskell.org> #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 rwbarton): Here is a real-life example with an added twist: http://stackoverflow.com/questions/34823628/calling-haskell-from-c -getting-multiple-definition-of-main-linker-error On the one hand, seeing occurrences of this confusing people "in the wild" argues towards doing something; but on the other hand, this particular instance illustrates how it is tricky to do something correct. How do we know whether `inc.o` and `Inc.o` are names that refer to the same file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 01:56:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 01:56:45 -0000 Subject: [GHC] #11468: testsuite should ignore config files Message-ID: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> #11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 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: -------------------------------------+------------------------------------- I always get a few test failures like the following. {{{ =====> T9360a(normal) 1 of 3 [0, 0, 0] cd ./driver && "/Users/gridaphobe/Source/ghc/build/D1805/inplace/test spaces/ghc-stage2" --interactive -e "" T9360a.run.stdout 2> T9360a.run.stderr Actual stderr output differs from expected: --- /dev/null 2016-01-20 16:43:09.000000000 -0800 +++ ./driver/T9360a.run.stderr.normalised 2016-01-20 16:43:09.000000000 -0800 @@ -0,0 +1,11 @@ +cannot satisfy -package pretty-show + (use -v for more information) + +: + Could not find module ?Text.Show.Pretty? + It is not a module in the current program, or in any known package. + +:7:25: + Variable not in scope: ppShow :: a -> String + +:1:1: Not in scope: ?pprint? \ No newline at end of file Actual stdout output differs from expected: }}} The failure is due to my `~/.ghci` file, which loads a few packages that ghc-head obviously hasn't built. The testsuite should ignore `~/.ghci` and any other user configuration files that might affect ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 02:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 02:48:56 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.947e4194a5fc27ab0c55f78f5a1e200c@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | 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 syd): Replying to [comment:21 thomie]: > To be clear: I'm not against this feature. Good error messages are important. I just think you should get some more feedback from others before spending time on implementation. Oh you're absolutely right. Your suggestion of a workflow sounds entirely agreeable. At the moment I'm in the middle of exams so that wikipage won't be created until at least Feb 13 2016. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 03:14:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 03:14:53 -0000 Subject: [GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible Message-ID: <045.1992743c6be5a313d344284f20ce0d35@haskell.org> #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.11 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: -------------------------------------+------------------------------------- While helping a Haskell beginner today, we came across this behavior and I wondered why there wasn't already a ticket for this problem in the tracker. In fact, this is technically a duplicate of #3217, but that ticket is long (and it was difficult to find!) so I just want to file a new ticket to summarize what needs to be done. The essential problem is that a user is editing a file that looks like this: {{{ {-# LANGUAGE OverloadedStrings #-} module A where ... some code ... }}} and they load this into ghci with `ghci A.hs`. They then might reasonably type a string into the GHCi prompt and expect it to be overloaded... but it will not be! They had to have invoked GHCi with `ghci -XOverloadedStrings A.hs`. This behavior is unexpected and not very nice. The proposal is this: (from https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15) GHCi should be changed so that at most one module is "fully open", currently denoted *M in GHCi's prompt. If a module M is "fully open", expressions typed at the GHCi prompt are interpreted (roughly) as if they were written in M itself. Specifically: * All the top-level things in the module are in scope * The per-module flags in {-# OPTIONS #-} and {-# LANGUAGE #-} pragmas * M's default declaration holds Note that currently more than one module can be fully open, and their top level scopes are merged. We propose to make that at most one. When compiling an expression typed on the GHCi command line: * Start with the baseline DynFlags * Apply flags specified on the original command-line * (Perhaps: apply flags specified by :set in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by :seti in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. Implementing this plan will require some representation changes. In particular, since we need to apply M's source-code flags in two difference places, we really need to remember the diffs with M, perhaps as a `(DynFlags -> DynFlags)` function or something. See also: https://ghc.haskell.org/trac/ghc/ticket/3217#comment:28 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 03:15:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 03:15:20 -0000 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> Message-ID: <061.26d8dc52439dc961c7d46e948d53f848@haskell.org> #3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 3202 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: I'm going to close this in favor of #11469 which doesn't have a long discussion before you get to the actual plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 04:58:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 04:58:24 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.cca3e7fe099307341abe59cf254935c7@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I like Simon's proposal in comment:16. Nice and neat. But it still might be nice to get the full pedantic thing if we want it, with no intention, ever, of putting it in `-Wall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 05:30:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 05:30:39 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.0ee9679d626ac99332babedab39575a9@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: 9218 | Blocking: Related Tickets: #9218 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): > > I have just removed all the special cases from the linker in ?Phab:D1805 > > Maybe you want to add something to the [wiki:Migration/8.0 migration guide] on that, or to the release notes maybe. Fair point, I'll add a todo for when the patch is accepted. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 07:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 07:18:48 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime Message-ID: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Relevant mailing list thread: https://mail.haskell.org/pipermail/ghc- devs/2016-January/011064.html At the moment, GHC's cross-compiling support requires you to build a cross-compiler for every target platform from scratch. (https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation) There are two reasons for this: 1. GHC uses a configure script to interrogate the GCC toolchain about the vagaries of cross-compilation, some parameters of which get baked into various build system scripts and header files and such. Some of this information wends its way into the final built GHC executable. 2. GHC needs to build the boot libraries, using the stage 1 compiler, targeting the cross compiler. It would be very useful to move this configuration from configure time to run time, so that a user can use GHC as a cross-compiler without having to recompile GHC. That is, we would like to (1) ensure that any information from the configure script can alternately be supplemented at runtime, (2) that users can cross-compile the boot libraries on-demand (since GHC won't ship with the ARM versions of the boot libraries), and (3) rearchitect GHC internally so that it handles knows to keep separate the interface files/package database for various cross compilation targets. Such a change will make cross-compiling more convenient (the iOS cross- compiler currently requires GHC to be built twice, once for ARM and once for the simulator!) and will also pave the way for supporting Template Haskell and compiler plugins in the cross-compiler, since a GHC that knows how to deal with both the target and host platforms can simply ensure that it only loads code built for the host platform (a user can then, if necessary, build code twice, once for the host for Template Haskell, and once for the target). Unclear points of design: * How should GHC get the information about the GCC cross-compiler toolchain (which currently is gotten by `configure`?) Preferably, not by running a `configure` script every time you invoke it. What is this information anyway? * How should GHC rebuild the boot libraries? Maybe `cabal-install` can simply handle this for you. Note: please update the top of this ticket as the design becomes clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 07:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 07:21:01 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.66b286892c1651db542c92065980ec8c@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #11378 @@ -45,0 +45,4 @@ + + Related tickets: #11378 (an alternate way to implement this without + implementing multitarget support. If this ticket is solved, that ticket is + moot.) New description: Relevant mailing list thread: https://mail.haskell.org/pipermail/ghc- devs/2016-January/011064.html At the moment, GHC's cross-compiling support requires you to build a cross-compiler for every target platform from scratch. (https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation) There are two reasons for this: 1. GHC uses a configure script to interrogate the GCC toolchain about the vagaries of cross-compilation, some parameters of which get baked into various build system scripts and header files and such. Some of this information wends its way into the final built GHC executable. 2. GHC needs to build the boot libraries, using the stage 1 compiler, targeting the cross compiler. It would be very useful to move this configuration from configure time to run time, so that a user can use GHC as a cross-compiler without having to recompile GHC. That is, we would like to (1) ensure that any information from the configure script can alternately be supplemented at runtime, (2) that users can cross-compile the boot libraries on-demand (since GHC won't ship with the ARM versions of the boot libraries), and (3) rearchitect GHC internally so that it handles knows to keep separate the interface files/package database for various cross compilation targets. Such a change will make cross-compiling more convenient (the iOS cross- compiler currently requires GHC to be built twice, once for ARM and once for the simulator!) and will also pave the way for supporting Template Haskell and compiler plugins in the cross-compiler, since a GHC that knows how to deal with both the target and host platforms can simply ensure that it only loads code built for the host platform (a user can then, if necessary, build code twice, once for the host for Template Haskell, and once for the target). Unclear points of design: * How should GHC get the information about the GCC cross-compiler toolchain (which currently is gotten by `configure`?) Preferably, not by running a `configure` script every time you invoke it. What is this information anyway? * How should GHC rebuild the boot libraries? Maybe `cabal-install` can simply handle this for you. Note: please update the top of this ticket as the design becomes clearer. Related tickets: #11378 (an alternate way to implement this without implementing multitarget support. If this ticket is solved, that ticket is moot.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 07:26:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 07:26:48 -0000 Subject: [GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling In-Reply-To: <045.6104ef63780cb1088603ac8080468c98@haskell.org> References: <045.6104ef63780cb1088603ac8080468c98@haskell.org> Message-ID: <060.765eeac14408ca1998f2f1dddc67507e@haskell.org> #11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11470 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #11470 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 07:51:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 07:51:14 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.bc93724bc5eb111191f54118b6bd209f@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): See also: - https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS - https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell - https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/CrossCompilation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 08:05:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 08:05:57 -0000 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> Message-ID: <061.35bc6867a74127812269a9508eb0ba8e@haskell.org> #3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 3202 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => * milestone: 8.0.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 08:07:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 08:07:36 -0000 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@haskell.org> Message-ID: <061.e81d038006c0ecd6c85fa5a53064e3c2@haskell.org> #3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 3202 Related Tickets: #11469 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11469 Comment: Removed the milestone, for the statistics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 08:14:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 08:14:40 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.6554524be443731521babe9b0c355915@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ericson2314): * cc: john_ericson@? (removed) * cc: Ericson2314 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 09:11:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 09:11:06 -0000 Subject: [GHC] #11471: Note [The kind invariant] in TyCoRep needs to be updated Message-ID: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> #11471: Note [The kind invariant] in TyCoRep needs to be updated -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeInType | 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 Note, found in TyCoRep, needs to be updated to reflect `TypeInType`. It should not reference `OpenKind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 09:35:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 09:35:23 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.9da8766ff70a976c681ab127abb731ee@haskell.org> #9159: cmm case, binary search instead of jump table -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: This was fixed in #10137, to be released with ghc-8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 09:54:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 09:54:47 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.2 Message-ID: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- GHC 7.10.1 didn't support `CallStack`, while its successors did. Yet in post-8.0 `master` (which needs to be buildable with the 7.10 series, including 7.10.1) references to CallStack have begun to sneak in to GHC. The first instance of this was 9d33adb6f352ad4e488067a8756928b3778920e0 but there will likely be more. I've fixed in this instance in Phab:D1812 by adding `#if` guards. These should be removed in GHC 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 09:55:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 09:55:51 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.a8d5bf0805613f0d4d82fccd451cab1b@haskell.org> #11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Fine. Now we just need someone to implement it! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 09:57:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 09:57:13 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations (was: Inconsistent warnings for unused binders) In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.51458187402e25cbc5433d1b443f7bb3@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:00:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:00:20 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.2 In-Reply-To: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> References: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> Message-ID: <061.e4a865c5b6514b6f9118fd0abc5c8d1d@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by jstolarek): Actually, the first instance was in 80d7ce8038a100f6797a89755c893c6f67f18a30 - that also broke the build for me because the guard incorrectly said `>= 710` instead of `> 710`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:07:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:07:46 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.d4cf8ba3e57efe683037291ea7e100d0@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #11378 | 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 Jan 21 10:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:08:26 -0000 Subject: [GHC] #11051: GHCi with +t option set shows type representations In-Reply-To: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> References: <046.80bf6e2eddeb6b8db1c64cf901c24623@haskell.org> Message-ID: <061.54e1910b2440bcc53a04d0080a96c591@haskell.org> #11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Phab:D1794 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e604e916a9727a22a392062096ea947df5fbe2c6/ghc" e604e91/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e604e916a9727a22a392062096ea947df5fbe2c6" Comments only Re Trac #11051 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:08:26 -0000 Subject: [GHC] #11459: Rather terrible error message due to excessive kind polymorphism In-Reply-To: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> References: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> Message-ID: <061.99a6f0d721b1a1d83a0d4ac1a8d986d7@haskell.org> #11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c572430cdade1d8c66fa9c4f1f251dfce09243f0/ghc" c572430c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c572430cdade1d8c66fa9c4f1f251dfce09243f0" Re-add missing kind generalisation When splitting H98/GADT syntax in ConDecl we lost a key kind-generalisation step. I also renamed tcHsTyVarBndrs to tcExplicitTKBnders, by analogy with tcImplicitTkBndrs. This fixes Trac #11459. Merge to 8.0. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:08:26 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.8722032b3702235ea2cfcd1d74ae653c@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"07afe448c3a83d7239054baf9d54681ca19766b0/ghc" 07afe44/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07afe448c3a83d7239054baf9d54681ca19766b0" Remove the check_lifted check in TcValidity This patch fixes Trac #11465. The check_unlifted check really isn't necessary, as discussed in Trac #11120 comment:19. Removing it made just one test-suite change, in indexed-types/should_fail/T9357, by allowing type family F (a :: k1) :: k2 type instance F Int# = Int to be accepted. And indeed that seems entirely reasonable. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:08:26 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.4696ba6af8afaaa8b2a3f219fbd8a0c3@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"07afe448c3a83d7239054baf9d54681ca19766b0/ghc" 07afe44/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07afe448c3a83d7239054baf9d54681ca19766b0" Remove the check_lifted check in TcValidity This patch fixes Trac #11465. The check_unlifted check really isn't necessary, as discussed in Trac #11120 comment:19. Removing it made just one test-suite change, in indexed-types/should_fail/T9357, by allowing type family F (a :: k1) :: k2 type instance F Int# = Int to be accepted. And indeed that seems entirely reasonable. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:08:26 -0000 Subject: [GHC] #11464: Type casts cause confusing error In-Reply-To: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> References: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> Message-ID: <061.e80f9c1057a2591336d62bd31c4bbae8@haskell.org> #11464: Type casts cause confusing error -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b2e6350fb23403f1c88c5cfed5270d78dbdb6573/ghc" b2e6350/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b2e6350fb23403f1c88c5cfed5270d78dbdb6573" Strip casts in checkValidInstHead This patch addresses Trac #11464. The fix is a bit crude (traverse the type to remove CastTys), but it's also simple. See Note [Casts during validity checking] in TcValidity }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:09:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:09:34 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.3c94eb1c6cf83001408368b865ca5d0c@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:10:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:10:55 -0000 Subject: [GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments In-Reply-To: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> References: <047.8e3bef77f3a38169b472bd5d04635a14@haskell.org> Message-ID: <062.3c88fc34ef5e0c411e6fa084e7ae103c@haskell.org> #9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: fixed | 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 bgamari): If Phab:D1807 is merged then this limitation will once again be lifted allowing. As it stands, this works, {{{#!hs {-# LANGUAGE PolyKinds TypeFamilies MagicHash DataKinds TypeInType #-} import GHC.Exts import GHC.Types class BoxIt (a :: TYPE 'Unlifted) where type Boxed a :: * boxed :: a -> Boxed a instance BoxIt Char# where type Boxed Char# = Char boxed x = C# x main :: IO () main = print $ boxed 'c'# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:13:06 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.9100becd1e509d88fa7c9b7fa9ae6947@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:3, the error message looks fine. I think you meant `instance Eq Char#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:13:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:13:57 -0000 Subject: [GHC] #11464: Type casts cause confusing error In-Reply-To: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> References: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> Message-ID: <061.845a512d57e82114ce19a547e2a8af15@haskell.org> #11464: Type casts cause confusing error -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11464 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T11464 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:14:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:14:50 -0000 Subject: [GHC] #11459: Rather terrible error message due to excessive kind polymorphism In-Reply-To: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> References: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> Message-ID: <061.44cee393be0733c4e7c74cefc016a48e@haskell.org> #11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | polykinds/T11459 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T11459 * status: new => merge Comment: Thanks for reporting this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 10:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 10:59:27 -0000 Subject: [GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command In-Reply-To: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> References: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> Message-ID: <065.a6fc594c3058b72cd2159b1e9527d3a8@haskell.org> #11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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 jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 11:42:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 11:42:12 -0000 Subject: [GHC] #11471: Note [The kind invariant] in TyCoRep needs to be updated In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.fa90d4ab351731624b9eb347d999c713@haskell.org> #11471: Note [The kind invariant] in TyCoRep needs to be updated -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 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): Bother. There are worms under this stone. Is this OK? {{{ type family F a :: k type instance F Int = Int# type instance F Bool = Int }}} This looks very bad to me. Now the runtime representation of `(F a)` might be boxed or unboxed. Eeek. And indeed `Type.typePrimRep` assumes that any `AppTy` is a boxed pointer; and any `TyConApp` whose tycon is not primitive is also a boxed pointer. So if we can have type families with a poly-kinded result, then we can't allow kind variables to be instantiated with `TYPE Unlifted` (or anything levity polymorphic). Sigh. And if we have type constructors like `State# :: TYPE Lifted -> TYPE Unlifted`, which we do, then similar problems occur if we have {{{ type instance F Char = State# }}} because now `(F Char Int)` has a zero-width representation. So we can't allow that kind variable to be instantiated with `* -> #` either. This is what `Note [The kind invariant]` was all about, and we have been quietly ignoring it. I think we must allow type families to have a poly-kinded result. So do we have to impose (painful to specify, painful to implement) restrictions on how kind variables can be instantiated. Ironically, we have just loosened this up; see #11120 comment:19, first bullet, and #11465. I'm really not sure what to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 11:45:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 11:45:40 -0000 Subject: [GHC] #11471: Note [The kind invariant] in TyCoRep needs to be updated In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.288cb325ac86e87081e2229349c68d8d@haskell.org> #11471: Note [The kind invariant] in TyCoRep needs to be updated -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 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): I wrote this code to try to get a seg-fault or something: {{{ import GHC.Exts import Data.Proxy type family F a :: k type instance F Int = Int# f :: Proxy a -> F a -> F a f _ x = x bad = f (undefined :: Proxy Int#) 3# }}} But instead I got some truly bizarre error messages {{{ Foo.hs:15:10: error: ? Expected kind ?Proxy Int#?, but ?undefined :: Proxy Int#? has kind ?Proxy Int#? ? In the first argument of ?f?, namely ?(undefined :: Proxy Int#)? In the expression: f (undefined :: Proxy Int#) 3# In an equation for ?bad?: bad = f (undefined :: Proxy Int#) 3# Foo.hs:15:35: error: ? Couldn't match a lifted type with an unlifted type When matching types F Int# :: * Int# :: # ? In the second argument of ?f?, namely ?3#? In the expression: f (undefined :: Proxy Int#) 3# In an equation for ?bad?: bad = f (undefined :: Proxy Int#) 3# }}} We get a bit more of a clue with `-fprint-explicit-kinds` {{{ Foo.hs:15:10: error: ? Expected kind ?Proxy * Int#?, but ?undefined :: Proxy Int#? has kind ?Proxy # Int#? ? In the first argument of ?f?, namely ?(undefined :: Proxy Int#)? In the expression: f (undefined :: Proxy Int#) 3# In an equation for ?bad?: bad = f (undefined :: Proxy Int#) 3# Foo.hs:15:35: error: ? Couldn't match a lifted type with an unlifted type When matching types F * Int# :: * Int# :: # ? In the second argument of ?f?, namely ?3#? In the expression: f (undefined :: Proxy Int#) 3# In an equation for ?bad?: bad = f (undefined :: Proxy Int#) 3# }}} but clearly life is not good here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 11:47:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 11:47:04 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening (was: Note [The kind invariant] in TyCoRep needs to be updated) In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.3a2d03b31ab353e4956d749d3fb51ae8@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:03:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:03:28 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.986d9ae4ae6a1fb983d1d7c28b3cbc58@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 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 bgamari): You also might be interested in [[https://phabricator.haskell.org/D1807#53426]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:16:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:16:50 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.0263110bf1badb58cbd072a6f8f0008c@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:17:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:17:52 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate Message-ID: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Ben found {{{ {-# LANGUAGE PolyKinds, TypeFamilies, MagicHash, DataKinds, TypeInType, RankNTypes #-} import GHC.Exts import GHC.Types type family Boxed (a :: k) :: * type instance Boxed Char# = Char type instance Boxed Char = Char class BoxIt (a :: TYPE lev) where boxed :: a -> Boxed a instance BoxIt Char# where boxed x = C# x instance BoxIt Char where boxed = id hello :: forall (lev :: Levity). forall (a :: TYPE lev). BoxIt a => a -> Boxed a hello x = boxed x {-# NOINLINE hello #-} main :: IO () main = do print $ boxed 'c'# print $ boxed 'c' print $ hello 'c' print $ hello 'c'# }}} This is plainly wrong because we have a polymorphic function `boxed` that is being passed both boxed and unboxed arguments. You do get a Lint error with `-dcore-lint`. But the original problem is with the type signature for `boxed`. We should never have a levity-polymorphic type to the left of an arrow. To the right yes, but to the left no. I suppose we could check that in `TcValidity`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:18:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:18:23 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.8d96e1ee360e6085d477c1f649195753@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -40,0 +40,2 @@ + + See also #11471 New description: Ben found {{{ {-# LANGUAGE PolyKinds, TypeFamilies, MagicHash, DataKinds, TypeInType, RankNTypes #-} import GHC.Exts import GHC.Types type family Boxed (a :: k) :: * type instance Boxed Char# = Char type instance Boxed Char = Char class BoxIt (a :: TYPE lev) where boxed :: a -> Boxed a instance BoxIt Char# where boxed x = C# x instance BoxIt Char where boxed = id hello :: forall (lev :: Levity). forall (a :: TYPE lev). BoxIt a => a -> Boxed a hello x = boxed x {-# NOINLINE hello #-} main :: IO () main = do print $ boxed 'c'# print $ boxed 'c' print $ hello 'c' print $ hello 'c'# }}} This is plainly wrong because we have a polymorphic function `boxed` that is being passed both boxed and unboxed arguments. You do get a Lint error with `-dcore-lint`. But the original problem is with the type signature for `boxed`. We should never have a levity-polymorphic type to the left of an arrow. To the right yes, but to the left no. I suppose we could check that in `TcValidity`. See also #11471 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:19:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:19:37 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.72d2f731e7ed585a726bd7999e7c12a0@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | 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 simonpj): * keywords: TypeInType => TypeInType, LevityPolymorphism * type: task => bug Comment: Replying to [comment:4 bgamari]: > You also might be interested in [[https://phabricator.haskell.org/D1807#53426]]. I was quite surprised to find that nothing blew up here. Eeek. See #11473. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:20:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:20:51 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.deb3426d3430800e9a81a6909d056004@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, 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 simonpj): * keywords: LevityPolymorphism => LevityPolymorphism, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:22:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:22:36 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.52b77eea6f794511fc8df67458497b04@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1799 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` in 6722f8d152a71ad7bccea37bd808fe5e3fd1c4e4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:23:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:23:55 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.4683bada95e9409691b3858fdb27f074@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): Simon's fix has been merged to `ghc-8.0` as fc5f85768c297c51a2366aa8af8afa33a85dd19c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:24:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:24:26 -0000 Subject: [GHC] #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" In-Reply-To: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> References: <046.fb046f4187507f5fe5c4d44196019747@haskell.org> Message-ID: <061.27b1d55e71c599e6a28b2450f0100db9@haskell.org> #11396: deriving Ix with custom ifThenElse causes "Bad call to tagToEnum#" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1797 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 82efc3e6f7664d7e744c533dea62ab61786486af. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:25:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:25:58 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.c2f9706e469f696b392f5d8a90f40a4a@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: "Rework derivation of type representations for wired-in things" merged to `ghc-8.0` as 19dc3cb3a73f72d62bc758e73a1fb3fee5039185. There is, however, more to this story. Simon's removal of the `check_lifted` checks have uncovered some deeper issues. See #11465 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:27:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:27:09 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.dddccda590e97727c8e9d00c1678a616@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 481ff7a08304011d7b9d95e399f7501d44951505 and 10183451279b97183addfea0382748fbb2e59e48. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:28:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:28:17 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.6d88c9b0bcd7b87fd5595b003a097b34@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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 Simon Peyton Jones ): In [changeset:"395ec414ff21bc37439194bb31a8f764b38b0fca/ghc" 395ec414/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="395ec414ff21bc37439194bb31a8f764b38b0fca" Allow implicit parameters in constraint synonyms This fixes Trac #11466. It went bad by accident in commit ffc21506894c7887d3620423aaf86bc6113a1071 Refactor tuple constraints }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:28:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:28:44 -0000 Subject: [GHC] #11459: Rather terrible error message due to excessive kind polymorphism In-Reply-To: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> References: <046.f54ff2a8915c78bc5113ef7b3cc25c3f@haskell.org> Message-ID: <061.378907cad724f60898d0a9ad762febb8@haskell.org> #11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | polykinds/T11459 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as e7e2ac8b740264527dd530c35cbbb6b63dc93640. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:29:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:29:08 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.e73b73d8dd0a09fb6837a538486196f6@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T11466 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:36:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:36:00 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.c95893109a3c9fc3fd7fd9d0cb5909a9@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): If option (2) isn't feasible I think I'd prefer to require the user to specify an explicit namespace over option (1). The parser is already quite complex; adding more complexity for a case that is arguably more clear if written explicitly doesn't seem worthwhile to me. That is just my two cents, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:36:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:36:37 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.8f2e05156a9a66c89904a4ef419aac71@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): * owner: => skvadrik -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:37:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:37:38 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.1f0ce4566291c45f0c664b9adec16a9a@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 bgamari): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:49:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:49:47 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.c71addf278922db1111f372f1b4c57db@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.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): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by asr): +1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:57:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:57:39 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.3a4f881c76319392f2a8e95476194144@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.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): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 12:59:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 12:59:33 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.3ad8339ec1bbc237e7893a38b25b3fa1@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): I definitely agree that parser is already complicated enough. I think option (2) is not hard to implement, only I'll be away from home until 6th February and hardly have any time to look into it (it doesn't mean that I've given up). Apologies for the delay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:00:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:00:05 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.e205b92cc3459a2ad98db8088024e36c@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType 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 bgamari): * priority: normal => highest * failure: None/Unknown => Incorrect warning at compile-time * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:00:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:00:18 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.957ee3f1be0d8fefaf039a039d1c912f@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -2,1 +2,1 @@ - {{{ + {{{#!hs New description: Ben found {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, MagicHash, DataKinds, TypeInType, RankNTypes #-} import GHC.Exts import GHC.Types type family Boxed (a :: k) :: * type instance Boxed Char# = Char type instance Boxed Char = Char class BoxIt (a :: TYPE lev) where boxed :: a -> Boxed a instance BoxIt Char# where boxed x = C# x instance BoxIt Char where boxed = id hello :: forall (lev :: Levity). forall (a :: TYPE lev). BoxIt a => a -> Boxed a hello x = boxed x {-# NOINLINE hello #-} main :: IO () main = do print $ boxed 'c'# print $ boxed 'c' print $ hello 'c' print $ hello 'c'# }}} This is plainly wrong because we have a polymorphic function `boxed` that is being passed both boxed and unboxed arguments. You do get a Lint error with `-dcore-lint`. But the original problem is with the type signature for `boxed`. We should never have a levity-polymorphic type to the left of an arrow. To the right yes, but to the left no. I suppose we could check that in `TcValidity`. See also #11471 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:04:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:04:48 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.442896fb60860c8cb9460467236f7293@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10935 Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:07:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:07:08 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning Message-ID: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | 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: -------------------------------------+------------------------------------- The following code when compiled with GHC 8 {{{#!hs {-# LANGUAGE Haskell2010, FunctionalDependencies, KindSignatures, ScopedTypeVariables, TypeOperators, UndecidableInstances #-} import GHC.Generics data Options data Value newtype Tagged s b = Tagged {unTagged :: b} class GToJSON f where gToJSON :: Options -> f a -> Value class SumToJSON f allNullary where sumToJSON :: Options -> f a -> Tagged allNullary Value class AllNullary (f :: * -> *) allNullary | f -> allNullary instance ( AllNullary (a :+: b) allNullary, -- <- removing this line causes a compile error SumToJSON (a :+: b) allNullary ) => GToJSON (a :+: b) where gToJSON opts = (unTagged :: Tagged allNullary Value -> Value) . sumToJSON opts }}} emits a warning {{{ bug.hs:19:10: warning: ? Redundant constraint: AllNullary (a :+: b) allNullary ? In the instance declaration for ?GToJSON (a :+: b)? }}} when commenting out the `AllNullary` constraint, this however results the compile error {{{ bug.hs:19:10: error: ? Could not deduce (SumToJSON (a :+: b) allNullary0) from the context: SumToJSON (a :+: b) allNullary bound by an instance declaration: SumToJSON (a :+: b) allNullary => GToJSON (a :+: b) at redconstr.hs:(19,10)-(22,24) The type variable ?allNullary0? is ambiguous ? In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for ?GToJSON (a :+: b)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:14:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:14:46 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.f1d546a4b469d3e4fd5f58df2da3a2fb@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point. Indeed the evidence for `AllNullary` is not used, but its functional dependencies are. I don't know how to reliably detect that. I suppose I could not warn if the class has functional dependencies. (Or maybe if any of its superclasses, transititively, do?) Meanwhile I think we've agreed that this warning will be off by default for 8.0 so you won't see it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:21:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:21:09 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.fa523a9952ba9a6a3472cdce7385f2c7@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #8326, | Differential Rev(s): #8317, #9159 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I don?t plan to look into this now, but whoever touches this code next and feels like improving the heuristics that decide whether to do a table or a binary search, see [ticket:9159#comment:5] for what the Java compiler does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:21:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:21:23 -0000 Subject: [GHC] #10137: Rewrite switch code generation In-Reply-To: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> References: <046.76db5d7024cf37118691ee86e6886b33@haskell.org> Message-ID: <061.4a53d972f44c60319af9155875d715ba@haskell.org> #10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #9159, | Differential Rev(s): #8326, #8317, #9159 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: #9157, #8326, #8317, #9159 => #9157, #9159, #8326, #8317, #9159 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:57:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:57:54 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.2 In-Reply-To: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> References: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> Message-ID: <061.6c8fbe2430c73d2a8d4e8fd272a4e69d@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ede055eb230ac33da276f1416678f99e32e83da2/ghc" ede055eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ede055eb230ac33da276f1416678f99e32e83da2" TyCoRep: Restore compatibility with 7.10.1 Sadly CallStack wasn't present in 7.10.1, breaking the build when bootstrapping from this version. This patch essentially disables CallStack support for stage1 builds with 7.10.*. This doesn't seem so unreasonable though as stage2 will still work. Test Plan: Validate with 7.10.1 Reviewers: gridaphobe, jstolarek, austin Reviewed By: jstolarek Subscribers: thomie, jstolarek Differential Revision: https://phabricator.haskell.org/D1812 GHC Trac Issues: #11472 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 13:57:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 13:57:54 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.fa2fc60d2bc48ab2817ad0b9b139ad14@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.10.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:D1617 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7cb893f562346d5aa986bd88863335aabbf7e95f/ghc" 7cb893f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7cb893f562346d5aa986bd88863335aabbf7e95f" Update and improve documentation in Data.Foldable Previously there were a few obsolete references to `Data.List` and the descriptions were lacking examples. Fixes #11065. Test Plan: Read it. Reviewers: ekmett, goldfire, hvr, austin Reviewed By: hvr Subscribers: nomeata, thomie Differential Revision: https://phabricator.haskell.org/D1617 GHC Trac Issues: #11065 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:00:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:00:16 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives Message-ID: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- GHC's simplifier prunes inaccessible alternatives from case expressions. E.g. {{{ case x of A y -> e1 _ -> ....(case x of A y -> r1 B -> r2 C -> r3) ... }}} It'll prune the `A` alternative from the inner case to get {{{ case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... }}} BUT, there is no independent check from Lint that this pruning does the Right Thing. Trac #11172 turned out to be a bug in the pruning, which led to something like {{{ case x of Left y -> e1 }}} but in fact `x` ended up being bound to `(Right v)` for some value `v`. But because there is only a single alternative left, GHC does not test the tag, but instead goes ahead and accesses it the `Right` value as if it was a `Left` value. And because of pointer-tagging, it'll assume the wrong tag on the pointer, and very soon you are in seg-fault land. So this ticket is to suggest: make Core Lint do it's best to check that all cases are in fact exhaustive. There are two ways in which we prune cases: * Enclosing pattern matches (as above) * GADT pattern matches may be exhaustive even when they don't mention all constructors. For the latter, it's impossible for Lint to reproduce all the reasoning of the type checker, but I bet that in 99.5% of the cases the existing function `dataConCantMatch` will do the job. So if Lit * Maintains an environment saying what each variable can't match (as the simplifier does) * Does a simple-minded `dataConCantMatch` test based on the typ of the scrutinee I think we'd be a long way forward. It's possible that a valid program could trigger a Lint report, but let's see. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:01:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:01:21 -0000 Subject: [GHC] #11464: Type casts cause confusing error In-Reply-To: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> References: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> Message-ID: <061.1ba634a699e3b67e47e9d497cee4be33@haskell.org> #11464: Type casts cause confusing error -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11464 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` in 76d8549d07df1fffa87a820cea1c556104ff382c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:01:51 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.0ae4d07573bb122fa73465b5b5977a0a@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` in 3b6b1700ac589155cdc9bc393c1ef27eecf8eaed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:02:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:02:15 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.b9874839e1dd92a4c247d57d92b9e4e8@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 simonpj): Thanks. So we are now convinced that there is only one bug. I wish that Core Lint checked for this; so I've opened #11475 to ask for help with that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:02:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:02:27 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.3f7ab4751165f4041325e4587d8ebe9c@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:02:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:02:40 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.ffee4d73f472d1a2ca6cf80cfbe256c7@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:03:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:03:25 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives In-Reply-To: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> References: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> Message-ID: <061.3f7dfa9ae2158f99c06f3e0f8bf5e393@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -20,2 +20,6 @@ - Right Thing. Trac #11172 turned out to be a bug in the pruning, which led - to something like + Right Thing. Yet, lacking such a check, a program can pass Lint and then + seg-fault, which is Very Bad. + + + Trac #11172 is an example. It turned out to be a bug in the pruning, + which led to something like New description: GHC's simplifier prunes inaccessible alternatives from case expressions. E.g. {{{ case x of A y -> e1 _ -> ....(case x of A y -> r1 B -> r2 C -> r3) ... }}} It'll prune the `A` alternative from the inner case to get {{{ case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... }}} BUT, there is no independent check from Lint that this pruning does the Right Thing. Yet, lacking such a check, a program can pass Lint and then seg-fault, which is Very Bad. Trac #11172 is an example. It turned out to be a bug in the pruning, which led to something like {{{ case x of Left y -> e1 }}} but in fact `x` ended up being bound to `(Right v)` for some value `v`. But because there is only a single alternative left, GHC does not test the tag, but instead goes ahead and accesses it the `Right` value as if it was a `Left` value. And because of pointer-tagging, it'll assume the wrong tag on the pointer, and very soon you are in seg-fault land. So this ticket is to suggest: make Core Lint do it's best to check that all cases are in fact exhaustive. There are two ways in which we prune cases: * Enclosing pattern matches (as above) * GADT pattern matches may be exhaustive even when they don't mention all constructors. For the latter, it's impossible for Lint to reproduce all the reasoning of the type checker, but I bet that in 99.5% of the cases the existing function `dataConCantMatch` will do the job. So if Lit * Maintains an environment saying what each variable can't match (as the simplifier does) * Does a simple-minded `dataConCantMatch` test based on the typ of the scrutinee I think we'd be a long way forward. It's possible that a valid program could trigger a Lint report, but let's see. Any volunteers? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:14:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:14:44 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.772cf416ac5f721be4a96bb750f7a1ea@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > This is bogus, because the equation for `T` has the parameters to `Either` reversed. Interesting, I was not aware of such a restriction on type family instances. Is this documented somewhere in the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type- families.html users' guide section] on type families? I was under the impression that as long as the instantiated type in the associated instance was equal to the instance head up to alpha equivalence, then it would be accepted, i.e., the above example is a valid type family instance, but the following is rejected with an error: {{{#!hs class C x where type T x instance C (Either a b) where type T (Either b (f a)) = b -> f a }}} {{{ ? Type indexes must match class instance head Found ?Either b (f a)? but expected ?Either a b? ? In the type instance declaration for ?T? In the instance declaration for ?C (Either a b)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:20:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:20:09 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.549c9bc56cb16c6c32334967388f8f8e@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by simonpj): That would also make sense. So you would also like to be able to write {{{ class C v where type T v instance C (Either a b) where type T (Either x y) = y -> x }}} But I think the current intent is "equal" not "equal up to alpha equivalence". Which do people like best? I in the class decl you obviously must use the same `v`; that's how you link the associated type to its class. In the instance we could loosen it. It's a usability issue not a technical one. Which is best? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:27:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:27:48 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.0c4c827799cfe7c0232b8b3f7493cc15@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think being able to use different type variables in the instance makes sense for a couple of reasons: 1. It's the way GHC has behaved for a while, so suddenly adding a new restriction feels questionable. I'm not sure if there's any code out there in the wild that relies on this behavior, but it wouldn't surprise me if there is. 2. You can already do things like this: {{{#!hs class C v where instance T x v y instance C (Either a b) where instance T a (Either a b) b = b -> a }}} That is, you can have other type variables mentioned in an associated type family that aren't from the class declaration (as long as at least one of the type variables is from the class). In that type instance, I don't know if it really makes sense to talk about a canonical ordering for the type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:36:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:36:50 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.79e1c091e276116f3b72c7fd8331992d@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.10.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:D1617 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:40:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:40:30 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.71a379ff8826603c5de2bb38601a18d5@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: goldfire => niteria * blocking: => 4012 * related: => #11371 Comment: This is a symptom of #11371. I just got this: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160121 for x86_64-unknown-linux): ASSERT failed! CallStack (from ImplicitParams): assertPprPanic, called at compiler/types/TyCoRep.hs:1868:61 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:1799:23 in ghc:TyCoRep substTyWith, called at compiler/types/Type.hs:799:46 in ghc:Type in_scope InScope [aph :-> k1_aph] tenv [aph :-> k1_aph] cenv [] ty (k1_aph -> *) -> (k2_apj -> *) -> Sum k1_aph k2_apj -> * needInScope [apj :-> k2_apj] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:44:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:44:25 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.4051ecd46741102f24afc34b743c505e@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType 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 goldfire): * owner: => goldfire Comment: This one is straightforward to check for, modulo the deeper issues in #11471. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:51:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:51:16 -0000 Subject: [GHC] #11056: Need to generate Typable info for promoted data constructors In-Reply-To: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> References: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> Message-ID: <061.523bd1f87dc09f64eb5ddfbbbb007090@haskell.org> #11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 can't reproduce this issue anymore on GHC HEAD (probably due to #11120 being fixed). Should we just close this as fixed, or should a test be added for `typeRep (Proxy :: Proxy '[True])`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 14:55:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 14:55:29 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.708ad265c0341eeae4c7625bf3414e69@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | 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 goldfire): Re comment:2: Try with `-fprint-explicit-coercions`. Here's what I think is happening, though I don't have a fresh enough build locally to check: `foo :: Proxy a -> F a -> F a` becomes `foo :: forall k2 (a :: *). Proxy * a -> F k2 a -> F k2 a`. Note that `F` is not polymorphic in the kind of `a`, which defaults to `*`. We also know that `k2` must be either `*` or `#`, because `F k2 a :: k2` is an argument of an arrow. GHC wisely defaults it to `*`, leading to the second error. Once we clean up kind errors with coercions, I think the error messages will improve. There's also clearly the word `kind` appearing where `type` should in the first message. But these errors are legitimate. As for the larger issue, we'll need to discuss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:04:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:04:02 -0000 Subject: [GHC] #11464: Type casts cause confusing error In-Reply-To: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> References: <046.358eb3b0ba10c0cbb54dd77a6b98ca44@haskell.org> Message-ID: <061.4f3b7c5558761821784bfdaa77b1c095@haskell.org> #11464: Type casts cause confusing error -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11464 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): One could theoretically want `tcSplitCastedTyConApp_maybe` which is somewhat less crude, but I agree that this works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:07:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:07:55 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.d5f331d36f72a4f9b525f7266c524814@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by goldfire): I think it's best to require the variables to be the same. They are the same under the hood, so they should be the same on top of the hood, too. The fact that we didn't require this previously is a bug, in my opinion. I don't see how the example in comment:5 argues otherwise. Yes, instances should allow non-linear uses of variables, but I don't see that as related to this overall issue. I could see someone arguing about spurious code breakage here, but I'm not too worried. And the change they would have to make is fully backward compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:12:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:12:18 -0000 Subject: [GHC] #11476: gcc leaves undeleted temporary files when invoked with a response file Message-ID: <047.e3b961b76b117f25353aec347110b896@haskell.org> #11476: gcc leaves undeleted temporary files when invoked with a response file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Split off from #10986. In changeset:296bc70b5ff6c853f2782e9ec5aa47a52110345e (present in 7.10.3, but not 7.10.2) ghc started using response files when invoking gcc as a linker, to work around command-line length limits. Unfortunately, gcc leaves behind a temporary file `/tmp/cc??????` when it is invoked with a response file. That means that every time we link an executable, gcc leaks a temporary file. In the course of a validate run (due mainly to the testsuite) that means thousands of temporary files. I'm not sure exactly which versions (or which OSes) are affected, but from ticket:10986#comment:5 it seems that at least gcc 4.6.3 on Windows is affected, and Windows is where we need the response file the most (since the command line length limit is shortest there). slyfox filed an upstream bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351 But in the mean time, this is pretty terrible. What can we do about it? One suggestion: ghc already creates a temporary directory like `/tmp/ghc1740_0`. So make a subdirectory `/tmp/ghc1740_0/cc`, and set `TMPDIR` (or whichever similarly-named environment variable has highest precedence) for the invocation of gcc to that directory. Then, when cleaning up, we blow away that whole directory. Then we are immune to gcc leaving behind any temporary files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:12:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:12:45 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.ae43d2e3c246d6990ac34e6fcf12d9b1@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): Okay so there are two issues here. * gcc leaves behind `/tmp/cc*` files whenever response files are used (upstream gcc bug filed by slyfox). * ghc leaves behind `/tmp/ghc*_*` directories ''rarely'' and under unknown circumstances. These issues seem quite distinct to me, and technically the `/tmp/cc*` files are not created by ghc, so I split off the first issue into its own ticket, #11476. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:22:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:22:45 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.5cd5d4a746cb77f3f4a0962462ad2c46@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): My question is: what exactly do we mean by "require the variables to be the same"? For example, would the following instance be rejected under this new rule? {{{#!hs class C v where type T v instance C (Either a b) where type T (Either _ b) = b }}} Also, what rules (if any) do we apply to non-linear type variables (like in the example above)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:32:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:32:32 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.e8fb3e4da04babf90634c6bba1356b82@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by simonpj): It's simple. Consider {{{ class C v where type T a b v cd }}} In any instance declaration, the type in the `v` position of the `type` instance must be the same as in the instance header: {{{ instance ... => C ty where type T p q ty r s = }}} I think we do (or at least should) also insist that `p`, `q`, `r`, `s` are distinct type variables, otherwise the type instance is more specific than the class instance, but that's a separate matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:32:42 -0000 Subject: [GHC] #11476: gcc leaves undeleted temporary files when invoked with a response file In-Reply-To: <047.e3b961b76b117f25353aec347110b896@haskell.org> References: <047.e3b961b76b117f25353aec347110b896@haskell.org> Message-ID: <062.d2e2508c03cfc65337485c71c57df994@haskell.org> #11476: gcc leaves undeleted temporary files when invoked with a response file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR: This also affects me on Linux (7.10.3 in Debian unstable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:34:46 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.efe0fac03fa80991b7e7a198d3b054af@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Should this be rejected? {{{#!hs class C x y where type T x y instance C (Either a b) (Maybe c) where type T (Either a b) (Maybe b) = a }}} GHC 8.1.20160117 gives: {{{ ? Type indexes must match class instance head Found ?Either a b? but expected ?Either a b? ? In the type instance declaration for ?T? In the instance declaration for ?C (Either a b) (Maybe c)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:35:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:35:48 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.51c22ce019e6e5e9c3d28d468debefaa@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes its should be rejected, as stated by my rule above -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:41:32 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.79dba725fcac255ca5109ab5a632b21d@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 simonpj]: > It's simple. Consider > {{{ > class C v where > type T a b v cd > }}} > In any instance declaration, the type in the `v` position of the `type` instance must be the same as in the instance header: > {{{ > instance ... => C ty where > type T p q ty r s = > }}} > I think we do (or at least should) also insist that `p`, `q`, `r`, `s` are distinct type variables, otherwise the type instance is more specific than the class instance, but that's a separate matter. Thank you for a formal description of what's going on, but I'm still confused about how this should behave w.r.t. wildcards. By the above rules, if you have {{{#!hs class Warning a where type T a instance Warning (Either a b) where ... }}} Then we'd have to do something like this: {{{#!hs instance Warning (Either a b) where type T (Either a b) = a }}} But this results in a warning on GHC 8.0! {{{ Defined but not used: type variable ?b? }}} And if you changed `b` to `_`, it would no longer follow the rules described above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:44:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:44:25 -0000 Subject: [GHC] #11477: Remove -Wamp Message-ID: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- This warning is intended as a temporary measure to aid the Applicative- Monad Proposal transition. It should be eventually removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:45:32 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.b8965f009fb4dcde9aed522e7d5adcca@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10935 Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: If I'm not mistaken this is resolved, * `-fwarn-tabs` is gone * `-fwarn-monomorphism-restriction` has been resuscitated * `-fwarn-unrecognised-pragmas` no longer exists * `-XAlternativeLayoutRule` and friends is handled in #11359 * `-fwarn-amp` will be handled in due time (created #11477 to track this) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 15:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 15:59:27 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.e0f938a540a52a2357af7ca6f51e438b@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): It's not a big deal, but I prefer the proposed change too. In my mind, when I write an instance {{{ instance C (Either a b) where ... }}} I'm really writing an instance for `Either a b` for each pair of specific, but unknown, types `a` and `b`. According to the class declaration {{{ class C x where type T x }}} I'm supposed to provide the value of `T` on the specific type `Either a b`. If I write `type T (Either b a) = ...`, then I haven't met that obligation. This argument is somewhat flimsy in that type variables in the head of an instance don't actually scope over the instance body in Haskell 98; but we're already so far outside Haskell 98 with associated type families that I don't mind. (With ScopedTypeVariables instance head type variables do scope over the body, which is the behavior most people expect, I think.) It also just seems more practical: I might reasonably read `type T (...) = b -> a` and doze off over the argument of `T`, expecting a sensible author to have made it match the instance head. Surprise! Technically this is a breaking change, but I feel that on balance, authors will be more glad to learn about non-matching associated type heads, which were probably unintentional, than annoyed that their code broke. However, we should do it either quickly, before the next 8.0 RC, or leave it until 8.2. Nothing critical about this change that I can see, so better not to slip it in at the last minute of a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:04:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:04:07 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.86f98b216a755174471fcce40d8014ae@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:8 simonpj]: > It's simple. Consider > {{{ > class C v where > type T a b v cd > }}} > In any instance declaration, the type in the `v` position of the `type` instance must be the same as in the instance header: > {{{ > instance ... => C ty where > type T p q ty r s = > }}} > I think we do (or at least should) also insist that `p`, `q`, `r`, `s` are distinct type variables, otherwise the type instance is more specific than the class instance, but that's a separate matter. We don't and I don't think we should. Isn't it okay to define multiple instances that refine the other parameters, like this (currently accepted)? {{{ class C v where type T v w instance C (Either a b) where type T (Either a b) Int = a type T (Either a b) Char = b }}} In fact you're not obliged to provide any equations for `T` at all (though we do warn in that case). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:06:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:06:36 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.6fdba7fc8320985bdbbc063535e599c7@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:11 RyanGlScott]: > [...] > > Then we'd have to do something like this: > > {{{#!hs > instance Warning (Either a b) where > type T (Either a b) = a > }}} > > But this results in a warning on GHC 8.0! > > {{{ > Defined but not used: type variable ?b? > }}} > > And if you changed `b` to `_`, it would no longer follow the rules described above. GHC 8.0 does warn about that but it shouldn't. See #11451. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:41:32 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.ccb47b14c564e243407da51cef3c1cf1@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes to comment:11. I still say that the args to the type family should be identical to in the icnstance header, in the positions that are linked by the class decl. No wildcards. As to comment:13, yes that's right. We do allow that generality. (But we don't in the default decl of an associated type, in a class decl; I was confused.) Summary of long thread: the Description of this ticket is still right! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:42:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:42:23 -0000 Subject: [GHC] #11468: testsuite should ignore config files In-Reply-To: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> References: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> Message-ID: <064.1353717c3236d54587e74dab3d1d4650@haskell.org> #11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.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 rwbarton): In general the testsuite handles this on a test-by-test basis, specifying `-ignore-dot-ghci` when using `--interactive`. In this case, though, this happened to uncover a real bug: we certainly shouldn't print the "Loaded GHCi configuration" message in `ghc -e`! Will file a new ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:47:20 -0000 Subject: [GHC] #11478: ghc -e shouldn't print "Loaded GHCi configuration" message Message-ID: <047.ab61d3400307177855148860dc3d1387@haskell.org> #11478: ghc -e shouldn't print "Loaded GHCi configuration" message -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Phab:D1756 added a message when ghci loads a configuration file. But `ghc -e` is secretly ghci too, and we certainly shouldn't print the message then, since the output `ghc -e` is likely to be consumed by a shell script or the like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:49:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:49:10 -0000 Subject: [GHC] #11479: GHC leaves GCC response files in /tmp Message-ID: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> #11479: GHC leaves GCC response files in /tmp -------------------------------------+------------------------------------- Reporter: tuncer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After building a random package with cabal, GHC leaves GCC response files in /tmp instead of deleting once done. Just in case, here's what such a file (/tmp/cc*) looks like: {{{ -plugin /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccwHAsFF.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared -o dist/dist-sandbox-58bccafc/build/libHSsplit-0.2.3-1yuUfUR0BKgqOQR1FQ3Jv- ghc7.10.3.so [...] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:51:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:51:12 -0000 Subject: [GHC] #11479: GHC leaves GCC response files in /tmp In-Reply-To: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> References: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> Message-ID: <060.c7cb024c10e6bd1b43b6f6c918818e49@haskell.org> #11479: GHC leaves GCC response files in /tmp -----------------------------+-------------------------------------- Reporter: tuncer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+-------------------------------------- Changes (by tuncer): * failure: None/Unknown => Other * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:51:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:51:47 -0000 Subject: [GHC] #11479: GHC leaves GCC response files in /tmp In-Reply-To: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> References: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> Message-ID: <060.57abee92a8a250e090fa4bb1cd0f2e41@haskell.org> #11479: GHC leaves GCC response files in /tmp -----------------------------+-------------------------------------- Reporter: tuncer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+-------------------------------------- Description changed by tuncer: @@ -4,1 +4,1 @@ - Just in case, here's what such a file (/tmp/cc*) looks like: + Here's what such a file (/tmp/cc*) looks like: New description: After building a random package with cabal, GHC leaves GCC response files in /tmp instead of deleting once done. Here's what such a file (/tmp/cc*) looks like: {{{ -plugin /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccwHAsFF.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared -o dist/dist-sandbox-58bccafc/build/libHSsplit-0.2.3-1yuUfUR0BKgqOQR1FQ3Jv- ghc7.10.3.so [...] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 16:57:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 16:57:11 -0000 Subject: [GHC] #11479: GHC leaves GCC response files in /tmp In-Reply-To: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> References: <045.eb15eceb27e338c8c41b19fc150fe491@haskell.org> Message-ID: <060.af5faba6117d4748d2c65b23e67bedb6@haskell.org> #11479: GHC leaves GCC response files in /tmp ------------------------------+-------------------------------------- Reporter: tuncer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11476 | Differential Rev(s): Wiki Page: | ------------------------------+-------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #11476 Comment: Thanks for the report! But I just filed #11476 for the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 17:23:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 17:23:22 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.0ee77fcd808fc1de9644f0d4cfd0ea53@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Excellent, thank you Simon for the fix! Also thanks to bgamari for the updated reproduction and jscholl for the further minimised test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 17:35:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 17:35:05 -0000 Subject: [GHC] #11468: testsuite should ignore config files In-Reply-To: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> References: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> Message-ID: <064.8507455f6c4afd591509e1bbef5592ca@haskell.org> #11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.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 gridaphobe): I get these types of errors on three tests, so I guess they're probably missing `-ignore-dot-ghci` {{{ make test TEST="load_short_name T9360a T9360b" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 18:37:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 18:37:52 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.23fb6de439a7c1e387174ad8493e5e06@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Another example of Core from [http://osdir.com/ml/general/2016-01/msg29309.html ghc-devs]: >> It?d probably need a built-in function >> {{{#!hs >> setCallStack :: CallStack -> (AppendsCallStack => a) -> a >> }}} > Correct. This is easy to write in Core but not in Haskell. We also need > something similar for Typeable, when we get a type-indexed version of TypeRep > {{{#!hs > withTypeable :: TypeRep a -> (Typeable a => r) => r > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 18:38:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 18:38:06 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.4b2f4a4f43296079e3928bc896d822e8@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Quick coinage: === Verb === to '''push one's own applecart''' * (''idiomatic'') To strive or push for efforts that realise one's own ideas or vision. === See also === * [https://en.wiktionary.org/wiki/actions_speak_louder_than_words#English actions speak louder than words] ([https://en.wiktionary.org/wiki/res,_non_verba#Latin res, non verba]) * to [https://en.wiktionary.org/wiki/put_one's_money_where_one's_mouth_is#English put one's money where one's mouth is] ---- Replying to [comment:1 goldfire]: > I think this would be quite useful. And quite a lot of work. Are you volunteering to do it? :) If there is support for the idea I can push my own applecart (`...`) and take it on, but I would need feedback from those more familiar with GHC internals to begin forming the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 18:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 18:45:49 -0000 Subject: [GHC] #11478: ghc -e shouldn't print "Loaded GHCi configuration" message In-Reply-To: <047.ab61d3400307177855148860dc3d1387@haskell.org> References: <047.ab61d3400307177855148860dc3d1387@haskell.org> Message-ID: <062.18bf55d8039fd07eda1c353715352edb@haskell.org> #11478: ghc -e shouldn't print "Loaded GHCi configuration" message -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D1817 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 18:52:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 18:52:01 -0000 Subject: [GHC] #11468: testsuite should ignore config files In-Reply-To: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> References: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> Message-ID: <064.62f9387d21249ad111d47e698ed0f891@haskell.org> #11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.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 rwbarton): I added `-ignore-dot-ghci` to those tests in 2ffc2606cfc58768ddc6dd53f270ba7088c43f3c. We could factor out all this repetition, though. How about a variable `TEST_HC_INTERACTIVE_OPTS` that is set to `$(TEST_HC_OPTS) --interactive -ignore-dot-ghci -v0`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 19:35:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 19:35:29 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.e55b7d198a39d0505678171bcb3ba35b@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Focusing on Core for now, we can reuse Haskell's syntax (some intersection between Haskell and Core syntax), see #11350, with minor sugar for functions: {{{#!hs {-# CORE id #-} id :: forall a. a -> a id @a (x :: a) = x {-# CORE add #-} double :: forall num. Num num => num -> num double (@ num) (numDict :: Num num) (x :: num) = (+) (@ num) numDict x x }}} or we could cheekily reuse Template Haskell. Like [https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/OverloadedLabels#Syntax this suggestions] to define a magic module for implicit values we can have define a magic module of quoters (`QuasiQuoter`s for sublanguages that are treated specially: {{{#!hs import GHC.Magic (core, stg) [core| id :: forall a. a -> a id = \ (@ a) (x :: a) -> x double :: forall num. Num num => num -> num double = \(@ num) (numDict :: Num num) (x :: num) -> + @ num numDict x x |] }}} or a combinator library where users code directly in Core AST, `data Expr b = Var Id | ...`. Some questions: * Dictionaries and their scope. * Writing function metadata. * Only top-level definitions? * ... Interested in other uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 19:41:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 19:41:58 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.3d5bc85b9a51060d76d831a4f03ff8f5@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms 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 Iceland_jack): While commenting on #11441, what about lambdas? {{{#!hs -- Should work, given proposal. id :: forall a. a -> a id @a x = x -- Also. id :: forall a. a -> a id (@ a) (x :: a) = x -- What about this? id :: forall a. a -> a id = \ (@ a) (x :: a) -> x -- Or this id :: b -> b id = \ (@ a) (x :: a) -> x }}} Same question extends to `LambdaCase`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 20:16:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 20:16:47 -0000 Subject: [GHC] #4248: Poor error message when openFile fails to open named pipe In-Reply-To: <048.e67ff3dc4c0c087b003f8ce86db16489@haskell.org> References: <048.e67ff3dc4c0c087b003f8ce86db16489@haskell.org> Message-ID: <063.aa594cd821cab4d93659b4f582611aa3@haskell.org> #4248: Poor error message when openFile fails to open named pipe -------------------------------------+--------------------------------- Reporter: Khudyakov | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"4c4a0a52d3ca5befd2a632544e9541703007e356/ghc" 4c4a0a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c4a0a52d3ca5befd2a632544e9541703007e356" Fix docstring GHC.IO.Handle.FD.openFileBLocking Fixes #4248. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 20:18:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 20:18:32 -0000 Subject: [GHC] #9149: Description of openFileBlocking is wrong In-Reply-To: <044.5c835f25372cd920667deec884e080e9@haskell.org> References: <044.5c835f25372cd920667deec884e080e9@haskell.org> Message-ID: <059.bdc4174e7d92d95a7691ad72e5b34b10@haskell.org> #9149: Description of openFileBlocking is wrong -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.8.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: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: => 8.0.1 Comment: You're right, I tested it. Fixed in commit 4c4a0a52d3ca5befd2a632544e9541703007e356 {{{ Author: Thomas Miedema Date: Thu Jan 21 21:16:05 2016 +0100 Fix docstring GHC.IO.Handle.FD.openFileBLocking Fixes #4248. }}} That ticket number should have been #9149. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 20:51:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 20:51:31 -0000 Subject: [GHC] #11461: Allow pattern synonyms to be bundled with type classes? In-Reply-To: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> References: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> Message-ID: <064.f5ac10caa7fdafd31d1835713a905dc5@haskell.org> #11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | PatternSynonyms 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 rwbarton): Probably obvious to the pattern synonym cognoscenti but you can change the export list to {{{ module Foo(Nullable, pattern Null) where }}} and use this style today. The disadvantages relative to "real" associated patterns are * no association between the class and the pattern as far as import/export is concerned * you have to give a single top-level definition of the pattern synonym, and do the per-instance work in an auxiliary function. I think you can always do this at negligible cost (other than syntactic noise). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 20:51:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 20:51:36 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.8531f28e1c3ac10505530f8dd2e85fac@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): See #11461 for how to approximate this feature in current GHC. Richard, how does your comment:7 apply here? Or to the example in #11224? The status quo seems to be that type arguments are "inputs", rather than "outputs", of the pattern synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:39:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:39:30 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.7af0da4c850dda643d30d6739a8d16fe@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by hvr): does this depend on #11429? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:42:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:42:40 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.068fcb38112027672acf828791971872@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1809 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"4c11db6377aa4fba0c4d70a1e9508247fd053bce/ghc" 4c11db6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c11db6377aa4fba0c4d70a1e9508247fd053bce" sphinx-build: fix python stack overflow (Trac #10950) Summary: commit a034031a102bc08c76a6cdb104b72922ae22c96b did not fix problem completely. Stack overflows still occasionally happen. Easy to test by the following Torture Test: while sphinx-build -T -N -E -a -b html \ -d docs/users_guide/.doctrees-html \ -D latex_paper_size=letter \ docs/users_guide docs/users_guide/build-html/users_guide do echo again done sphinx build large nested data structures when parses GHC manual (docs/users_guide/glasgow_exts.rst is 455KB in size) which can't be serialized useing default python call stack depth of 1000 calls. The patch increases stack depth 10 times. Survived 2 hours of Torture Test. Signed-off-by: Sergei Trofimovich Test Plan: ran Torture Test to make sure it is stable Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1809 GHC Trac Issues: #10950 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:44:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:44:18 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.1a2cba5287fe64f5bf8472d9a735ea15@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): I found one cause of leaked `ghc*_*` directories from the test suite: `WAY=ghci` tests where executing `main` raises an exception. `WAY=ghci` tests are run with ghci input like {{{ :set prog cgrun016 :set args :! echo ===== program output begins here :! echo 1>&2 ===== program output begins here System.IO.hSetBuffering System.IO.stdout System.IO.LineBuffering GHC.TopHandler.runIOFastExit Main.main Prelude.>> Prelude.return () }}} If its argument (`Main.main`) raises an exception, `runIOFastExit` calls `shutdownHaskellAndExit()` with `fastExit=1`, which just calls `exit()`. So, GHC has no chance to clean up. This seems like more of a testsuite issue than a GHC issue. I'll let the testsuite finish to see if there are any more cases where it leaves behind a `ghc*_*` directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:47:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:47:25 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.7b07610ee92b4045bb5eb3afe067a8ad@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: #11449, #11451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11449, #11451 Comment: Oh, I wasn't aware of #11449 and #11451. Those are pretty important context for navigating this. I don't have any objection (in principle) to requiring that the class instance types be the same as the associate types. All I ask is please allow me to write something like this if I want to: {{{#!hs instance C (Either a _) where type T (Either a _) = a }}} I'm quite fond of using wildcard types wherever possible, and I'd hate to lose that due to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:49:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:49:43 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.787bf1be1d3f9fa2f18df11c8623d3bc@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gridaphobe): It's definitely not just a testsuite issue. I get the `/tmp/ghc*` directories on a server that I do not use for GHC hacking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:56:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:56:34 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.e606221bc9a0cbdcca0f89c69592f0ab@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): Okay, but it would be very helpful to have a concrete reproducer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 21:58:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 21:58:45 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.c9d9e80e0c77743cbb540a68183b5ac7@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm a bit confused about example (C), since I don't think this: {{{#!hs class C [a] where type T [a] = Int }}} is legal (which is what example (C) is, just with `_` instead of `a`). Did you mean something like this? {{{#!hs class C _ where type T _ = Int }}} or this? {{{#!hs instance C [_] where type T [_] = Int }}} I can understand objecting to the former (similarly, you'd reject `data T _ = MkT _`, right?), but I certainly want the latter to be legal, especially if we require the class instance types to be the same as the associated type family types?otherwise, I'd have no way of [https://ghc.haskell.org/trac/ghc/ticket/11450#comment:16 wildcard-ing out unused types in such a scenario]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:20:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:20:38 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.d0ab0ba84f7322f5ed992eede3d923d9@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): Okay! There were two non-`WAY=ghci` tests that also left behind a temporary directory: `ghc-e005` and `T3890`. They are both `ghc -e`-related, but don't involve this `GHC.TopHandler.runIOFastExit` stuff, so they are real bugs. As hinted at by `ghc-e005`, `runghc` has the same behavior. {{{ rwbarton at morphism:/tmp$ rm -rf ghc* rwbarton at morphism:/tmp$ cat err.hs main = error "oops" rwbarton at morphism:/tmp$ runghc err.hs err.hs: oops rwbarton at morphism:/tmp$ echo ghc* ghc31610_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:28:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:28:07 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.7324985a7cafc12de9716ec594f6334b@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): Nontermination is also a problem for `runghc`, and probably a more common scenario. {{{ rwbarton at morphism:/tmp$ rm -rf ghc* rwbarton at morphism:/tmp$ cat loop.hs main = main rwbarton at morphism:/tmp$ runghc loop.hs ^C rwbarton at morphism:/tmp$ echo ghc* ghc31647_0 }}} In `ghc -e`/`runghc`, perhaps it would be possible to clean up the temporary directory before executing the expression/program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:29:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:29:46 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.3c11a904b8308e23a36aec72fbbeccdb@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: #11218, #9037 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by thomie): * related: #11218 => #11218, #9037 Comment: Also discussed in #9037. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:30:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:30:22 -0000 Subject: [GHC] #9037: Add option to make selected warnings errors In-Reply-To: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> References: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> Message-ID: <057.53db63af54099b062f3617ff9768d9f4@haskell.org> #9037: Add option to make selected warnings errors -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11219 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11219 Comment: There is a new ticket for this now: #11219. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:38:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:38:54 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux In-Reply-To: <043.041301d73710117066e0bc737fc4c18c@haskell.org> References: <043.041301d73710117066e0bc737fc4c18c@haskell.org> Message-ID: <058.d8e7add6e7014559b621f903ad26b2d3@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux -------------------------------------+------------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 (Linking) | Keywords: panic, Resolution: | dynamic linking Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: GHCi => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:44:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:44:02 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.c1c27f07db78a7e6804bfe996911aaa4@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1809 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:57:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:57:30 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.864fa448a21c9581085c9897ccd5022c@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Removing `-split-objs` also solves the following tickets: * #11315 * #8964 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 22:58:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 22:58:29 -0000 Subject: [GHC] #8992: Instructions for using gdb with GHC on Windows In-Reply-To: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> References: <045.5da142d588020e3fc1397add8a636ef7@haskell.org> Message-ID: <060.82e7a4dae8bd0f289bbe48705dff8458@haskell.org> #8992: Instructions for using gdb with GHC on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Documentation | Version: Resolution: worksforme | Keywords: msys,msys2 Operating System: Windows | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Phyx- thinks this is not an issue anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:00:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:00:06 -0000 Subject: [GHC] #11476: gcc leaves undeleted temporary files when invoked with a response file In-Reply-To: <047.e3b961b76b117f25353aec347110b896@haskell.org> References: <047.e3b961b76b117f25353aec347110b896@haskell.org> Message-ID: <062.012e7cbf0943814e3c8483bf67541357@haskell.org> #11476: gcc leaves undeleted temporary files when invoked with a response file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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 slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:14:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:14:28 -0000 Subject: [GHC] #8947: Depending on hint/ghc API fixes the binary version I can use In-Reply-To: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> References: <042.0b84808e71990b7e49b9c7a55ecf27f4@haskell.org> Message-ID: <057.ecf6f4e32080e4e4e1187252c8797580@haskell.org> #8947: Depending on hint/ghc API fixes the binary version I can use -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: invalid | 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 thomie): * status: new => closed * resolution: => invalid Comment: Replying to [comment:3 ezyang]: > Cabal bug: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:19:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:19:16 -0000 Subject: [GHC] #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" In-Reply-To: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> References: <047.d45db81c2a114a0b8481c5b5010dc503@haskell.org> Message-ID: <062.6249170deadf99443b5c86a9a6538b81@haskell.org> #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" ---------------------------------+-------------------------------------- Reporter: tbelaire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: invalid | 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 thomie): * status: new => closed * resolution: => invalid Comment: https://github.com/hdevtools/hdevtools/ seems to be active. This issue has probably been fixed, and wasn't a GHC bug to begin with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:33:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:33:16 -0000 Subject: [GHC] #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. In-Reply-To: <050.1906743244648eb3189d64db5510846c@haskell.org> References: <050.1906743244648eb3189d64db5510846c@haskell.org> Message-ID: <065.a67305e207ccc4fc418f300a23429184@haskell.org> #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. -------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.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 thomie): * cc: ekmett (added) * component: Compiler => Core Libraries @@ -5,0 +5,1 @@ + @@ -8,1 +9,2 @@ - }} + }}} + New description: The ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour: {{{ reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 foo"),(34.567,"e8 foo"),(3.4567e9," foo")] }}} Clearly only the last parse in the list is the Right Thing, and any parser which returns "34.0" when given "34.567" is doing it wrong. The problem came from the implementation of "optional". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this: {{{ fractPart <- optional "" $ do _ <- char '.' munch1 isDigit }}} The problem is that "optional" uses the symmetric choice operator (+++). I wrote this to work around the problem: {{{ myOpt d p = p <++ return d }}} This uses the left-biased choice, so as soon as the parser sees the "." it commits to the fractional part. However this still isn't the Right Thing. {{{ reads "34." :: [(Double, String)] = [(34.0, ".")] }}} but the parser above will fail to read it. Furthermore there are a number of combinators built on "+++" in ReadP, and it seems wrong to have left- biased variants of all of them. So what seems to be needed is some kind of "cut" operator, analogous to the Prolog "!" cut, which says that if you have got this far then you should commit to this parse and forget all the others. But it would have to be delimited because I only want that cut to apply to my Decimal type: if someone calls my Decimal parser then I don't want their parser to commit to an entire parse just because I have. So I think the feature I'm looking for is a delimited back-track akin to "prompt" in delimited continuations. But my monad-fu isn't good enough to design it. -- Comment: > my monad-fu isn't good enough to design it. It's two year later, maybe your monad-fu is good enough to design it now? See [wiki:WorkingConventions/AddingFeatures] for how to submit a patch. Or maybe the CLC has something to say about this feature request? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:37:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:37:34 -0000 Subject: [GHC] #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX In-Reply-To: <047.e5ea9e7d9a3c420fa31087f485544b00@haskell.org> References: <047.e5ea9e7d9a3c420fa31087f485544b00@haskell.org> Message-ID: <062.7520de6e7f17c4711e717eb2d179adbb@haskell.org> #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #8744 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #8744 Comment: Thanks for reporting. I think this is a duplicate of #8744, which was reported around the same time for OS X, and later closed as fixed. Please open a new ticket if you're still running into problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:44:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:44:38 -0000 Subject: [GHC] #8907: Un-zonked kind variable passes through type checker In-Reply-To: <047.8d583b99a10a02d33fcf9e56e368fd06@haskell.org> References: <047.8d583b99a10a02d33fcf9e56e368fd06@haskell.org> Message-ID: <062.3f59eab633eae8ad22a255f275a44ed8@haskell.org> #8907: Un-zonked kind variable passes through type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 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 thomie): * priority: normal => low Comment: Richard, can this ticket be closed? Output with ghc-7.10.3 is: {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) TYPE SIGNATURES TYPE CONSTRUCTORS type role Poly{tc} phantom data Poly{tc} (a :: k) COERCION AXIOMS Dependent modules: [] Dependent packages: [base-4.8.2.0, ghc-prim-0.4.0.0, integer-gmp-1.0.0.0] Bug.hs:1:1: ==================== Typechecker ==================== }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:48:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:48:41 -0000 Subject: [GHC] #8904: haddock displays GHC.Types.Coercible as a datatype In-Reply-To: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> References: <046.9569975d8a2129291c9ce95dd884053d@haskell.org> Message-ID: <061.d156731b293f240f9dbc76052b90d99c@haskell.org> #8904: haddock displays GHC.Types.Coercible as a datatype -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: GHC API | Version: 7.9 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8894 | Differential Rev(s): Phab:D300 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Seems fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:53:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:53:33 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.f1ae9721f5afa817c5a304594e021040@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | 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 simonpj): * owner: => goldfire Comment: Richard and I developed a plan this afternoon. '''Principle''': the kind of a type tells you its runtime representation (both width and pointer-hood). Currently we have {{{ data Levity = Lifted | Unlifted }}} With this new principle we would have {{{ data Levity = L -- Lifted, boxed, represented by a pointer | UB -- Unlifted, boxed, represented by a pointer | UV -- Unboxed, zero width | UW32 -- Unboxed, represented by a 32 bit word | UW64 -- Unboxed, represented by a 64 bit word | UF32 -- Unboxed, represented by a 32 bit float | UF64 -- Unboxed, represented by a 64 bit float ...etc... }}} Pretty much one case for each constructor in `PrimRep`. And that's it really. Now `typePrimRep` just takes the kind, and converts it to a `PrimRep`. This is a nice generalisation, and (we think) solves the problem. We need a Levity wiki page!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 21 23:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jan 2016 23:59:27 -0000 Subject: [GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong In-Reply-To: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> References: <047.ea86c023b4962335e095d1f92b0177e9@haskell.org> Message-ID: <062.8152bd958562b3d1f02f5e8393c0cef7@haskell.org> #8859: import conditionalization in System.Posix.Files.Common is wrong -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: hvr fixed this in https://github.com/haskell/unix/commit/03632e32eb1d2e8f5d41ddc0f81bc6eff6a343c9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:01:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:01:26 -0000 Subject: [GHC] #8850: (Compositional) function mkWeakChan In-Reply-To: <045.3d3ee9b3fbd2ed27796cea6f43168286@haskell.org> References: <045.3d3ee9b3fbd2ed27796cea6f43168286@haskell.org> Message-ID: <060.38ccf8502945cff34fe16e475a4b1b6d@haskell.org> #8850: (Compositional) function mkWeakChan -------------------------------------+------------------------------------- Reporter: bholst | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #7285 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * status: new => closed * resolution: => invalid * related: 7285 => #7285 Comment: Please submit a libraries proposal first, see https://www.haskell.org/haskellwiki/Library_submissions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:10:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:10:55 -0000 Subject: [GHC] #8830: internal error: Misaligned section: 18206e5b on Windows In-Reply-To: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> References: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> Message-ID: <062.59c5b74190fe4d03cdf7d4857d2457b0@haskell.org> #8830: internal error: Misaligned section: 18206e5b on Windows -------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Changes (by thomie): * status: infoneeded => closed * resolution: => invalid Comment: Closing, as no response from submitter. Without a reproducible test case we can't do anything. GHC on Windows is much better than it was one year ago, so hopefully this is fixed as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:10:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:10:59 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.15cdb27f62933f9a0b0e9fcf3c37de87@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): Well it's not so easy for `ghc -e` because there might be multiple `-e` arguments. So we can't exit the GHC session before executing the first argument, since the second argument might be `:t it` or something. The code structure is such that it currently is not easy to clean up temporary files in the middle of a GHC session, nor is it clear when it is safe to do so. We could probably handle the exceptional exit case better though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:14:13 -0000 Subject: [GHC] #11460: OverloadedStrings cause error in annotation In-Reply-To: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> References: <044.b3646c82567b2ed25f8b746ce24ac1df@haskell.org> Message-ID: <059.1c1c160c89deabc59d49576b0e77a197@haskell.org> #11460: OverloadedStrings cause error in annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: 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 rwbarton): * status: new => closed * resolution: => invalid Comment: Yes, it ''is'' an overloaded literal, so it desugars to {{{ {-# ANN module (fromString ("HLint: ignore Eta reduce" :: String)) #-} }}} The return type of `fromString` is ambiguous, as GHC says. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:25:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:25:06 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.3db02289f5d0ada57aa01da61c6c7885@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: arm => Generics * cc: erikd (removed) * os: Linux => Unknown/Multiple * architecture: arm => Unknown/Multiple * failure: Compile-time crash => Compile-time performance bug Comment: bgamari: you seem to have neglected to attach anything? But I'm going to guess the issue is similar to #11415. Not an issue with GHC's `deriving Generic`, directly, but with a Generic-based default definition for another class (here Serialize). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:33:12 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.1381bd9850eaf707c4fd7a397c0de7a8@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -11,2 +11,2 @@ - class C [_] where -- Not allowed - type T [_] = Int -- Not allowed + instance C [_] where -- Not allowed + type T [_] = Int -- Not allowed New description: GHC doesn't treat `_` consistently in type declarations {{{ -- Example A data T _ = MkT -- Not allowed -- Example B class C a where type T a -- Example C instance C [_] where -- Not allowed type T [_] = Int -- Not allowed -- Example D data family D a data instance D [_] = MkD -- Allowed -- Example E type family F a type instance F [_] = Int -- Allowed }}} This seems inconsistent and annoying (see [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026114.html email thread]). Really, we should consistently treat `_` in a binding position simply as ''a binder that binds nothing'', just like at the term level. But in Haskell 98 `_` is a reserved identifier, so these programs are illegal. We use `PartialTypeSignatures` to allow `_` in occurrence positions in types. Should the same flag enable `_` in binding positions? It would seem a little odd to require `PartialTypeSignatures` for (A) and (C). Any suggestions? A couple of wrinkles. First, since `_` binds nothing, it certainly doesn't bind occurrences of `_`. Thus for example, with `PartialTypeSignatures` {{{ instance C [_] where op = .... (let f :: _ -> _ f = e in ...) ... }}} The occurrences of `_` in `op`'s RHS are ''not'' bound by the `_` in the `instance` header. (The would be if all three were `a`, say.) Rather the occurrences of `_` are holes in the type signature and should be separately reported as such. Second, the implementation would be tricky in one spot: {{{ class C a where type T a instance C (Either _ _) where type T (Either _ _) = ... }}} We must check that the type family instance is at the same type as the class. Do we want to insist that it looks ''exactly'' the same, or would you be allowed to say this? {{{ instance C (Either _ _) where type T (Either a b) = a -> b }}} My instinct is to say "exactly the same" for now anyway. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 00:34:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 00:34:33 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.497bf156dc3e2ebc37d76186cb8ceb8c@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I meant `instance` sorry. I've fixed the ticket description. Remember the description describes current behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 01:19:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 01:19:06 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.3ad6f0fd501563c061f8db131268dd59@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I found another inconsistency with regards to datatypes vs. data families and visible type application. Let's define a datatype first: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160120: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/xnux/.ghci ?> :set -XTypeInType -XTypeApplications ?> data T k2 k4 (f :: k1 -> k2 -> k3 -> k4) = T ?> :t T T :: forall k1 k3 k2 k4 (f :: k1 -> k2 -> k3 -> k4). T k2 k4 f ?> :t T @Int T @Int :: forall k3 k2 k4 (f :: Int -> k2 -> k3 -> k4). T k2 k4 f }}} Nothing surprising here. The type variables are topologically sorted such that the last three variables correspond to the specified type variables. Looks good. But if I define the equivalent data family instance, I get a surprisingly different result: {{{ ?> :set -XTypeInType -XTypeApplications -XTypeFamilies ?> data family T (a :: k1) (b :: k2) (c :: k3) ?> data instance T k2 k4 (f :: k1 -> k2 -> k3 -> k4) = T ?> :t T T :: forall k2 k4 k1 k3 (f :: k1 -> k2 -> k3 -> k4). T k2 k4 f ?> :t T @Int T @Int :: forall k4 k1 k3 (f :: k1 -> Int -> k3 -> k4). T Int k4 f }}} This time, the kind variables are in a completely different order! The specified kind variables now come before the invisible kind variables, and as a result, `T @Int` has a completely different type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 01:55:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 01:55:19 -0000 Subject: [GHC] #11380: Compiling a 10.000 line file exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.1c2aa4de4f6979990b060db7270a330a@haskell.org> #11380: Compiling a 10.000 line file exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 rwbarton): * priority: high => normal Comment: Let's stick to the array-based parser since that's what the original issue was about. Then there's no problem compiling, either with or without optimizations. The problem is only with ghci for some reason. Trying with `-v`, there seems to be some major early difference when building with ghc vs. ghci. {{{ rwbarton at morphism:/tmp/pyn$ ghc-7.10.1 -fforce-recomp -c dist/build/Language/Python/Pyn/Parser/Parser.hs -O0 -ilib -idist/build -v -this-package-key pyn_4LeYrll2NJX6hY3DO8vvbp Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.4 [...] *** Desugar: Result size of Desugar (after optimization) = {terms: 214,221, types: 3,864,905, coercions: 74,929} [... everything is fine] }}} {{{ rwbarton at morphism:/tmp/pyn$ ghci-7.10.1 dist/build/Language/Python/Pyn/Parser/Parser.hs -ilib -idist/build -v -this-package-key pyn_4LeYrll2NJX6hY3DO8vvbp [...] [10 of 10] Compiling Language.Python.Pyn.Parser.Parser ( dist/build/Language/Python/Pyn/Parser/Parser.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 220,453, types: 414,293,970, coercions: 75,337} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 220,516, types: 419,756,722, coercions: 577,145} Result size of Simplifier iteration=2 = {terms: 220,516, types: 419,756,722, coercions: 370,154} Result size of Simplifier = {terms: 220,514, types: 419,756,719, coercions: 370,206} *** Tidy Core: Result size of Tidy Core^CInterrupted. [here memory usage exploded] }}} What would cause this huge difference? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 02:05:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 02:05:37 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.e04b7a7ba7e934061bf79c23cf5ba6ed@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | numeric/should_run/T9407 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I wonder if this might have been the same bug as #10521. If so then it should be broken in 7.8 and 7.10.1 but not 7.6 or 7.10.2. I have no specific theory about why it would be Windows-only though. If someone would care to test 7.10.1 and 7.6 on Windows, I would be curious to know the results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 02:19:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 02:19:11 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.edb9f57fb76c0946e45b871f70d88025@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: | -------------------------------------+------------------------------------- Comment (by dobenour): (1) is probably an LLVM bug, since GHC now uses LLVM's prefix data support. LLVM should be responsible for ensuring that the prefix data is properly handled by the assembler and linker. (2) can be solved by either 32-byte aligning the stack or disabling AVX instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 03:02:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 03:02:34 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances Message-ID: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: PolyKinds, | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10318 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looks like I spoke too soon when I said all my examples worked in #10318 -- it doesn't seem to work when the superclass cycle gets sufficiently interesting, possibly caused by the use of `PolyKinds` in the style mentioned in #9201. I took my `hask` code, and removed the shimming hacks above, and the following stripped down example sends the compiler into an infinite loop, which I believe should be able to work: {{{#!hs {-# language KindSignatures, PolyKinds, TypeFamilies, NoImplicitPrelude, FlexibleContexts, MultiParamTypeClasses, GADTs, ConstraintKinds, FlexibleInstances, FunctionalDependencies, UndecidableSuperClasses #-} import GHC.Types (Constraint) import qualified Prelude data Nat (c :: i -> i -> *) (d :: j -> j -> *) (f :: i -> j) (g :: i -> j) class Functor p (Nat p (->)) p => Category (p :: i -> i -> *) class (Category dom, Category cod) => Functor (dom :: i -> i -> *) (cod :: j -> j -> *) (f :: i -> j) | f -> dom cod instance (Category c, Category d) => Category (Nat c d) instance (Category c, Category d) => Functor (Nat c d) (Nat (Nat c d) (->)) (Nat c d) instance (Category c, Category d) => Functor (Nat c d) (->) (Nat c d f) instance Category (->) instance Functor (->) (->) ((->) e) instance Functor (->) (Nat (->) (->)) (->) }}} Sorry for the largish example, but I don't know how to strip it down smaller than the 6 instances that remain. One potentially telling observation is that without the instances it compiles, and produces what I expect, so the `UndecidableSuperClasses` part seems to be letting the classes compile, but there seems to be a bad interaction with the way the instances work. Also, in this stripped down form, I can remove the use of `UndecidableInstances` and that avoids the spinning problem, but once I flesh it out further I need `UndecidableInstances` in the "real" version of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 03:02:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 03:02:51 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.663934602af823e477d10463df70d478@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * version: 7.10.3 => 8.0.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 03:39:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 03:39:50 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.88bdc555de599eca7ec95d9d41a25c6f@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): There also seems to be a bad interaction with the `?callStack` machinery. Here is a differently modified test case: {{{ {-# language KindSignatures, PolyKinds, DataKinds, TypeFamilies, RankNTypes, NoImplicitPrelude, FlexibleContexts, MultiParamTypeClasses, GADTs, ConstraintKinds, FlexibleInstances, TypeOperators, ScopedTypeVariables, UndecidableSuperClasses, FunctionalDependencies #-} import GHC.Types (Constraint) import qualified Prelude data Dict p where Dict :: p => Dict p newtype p :- q = Sub (p => Dict q) data Nat (c :: i -> i -> *) (d :: j -> j -> *) (f :: i -> j) (g :: i -> j) class Functor p (Nat p (->)) p => Category (p :: i -> i -> *) where type Ob p :: i -> Constraint class (Category dom, Category cod) => Functor (dom :: i -> i -> *) (cod :: j -> j -> *) (f :: i -> j) | f -> dom cod bug :: Functor c d f => Ob c a :- Ob d (f a) bug = Prelude.undefined }}} I attempted to place `undefined` there as a placeholder while I worked on the surrounding code, but compiling `bug` causes {{{ solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [W] $dIP_a15a :: ?callStack::GHC.Stack.Types.CallStack (CDictCan)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Raising the limit gets me right back to the same unsolved constraint. Without the class cycle, we don't spin forever trying to find a `?callStack`. It seems odd that looking for `?callStack` would cause us to unroll superclasses though, as implicit parameters can't be a superclass of any class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 08:08:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 08:08:40 -0000 Subject: [GHC] #9407: Program produces different output when compiled with -O In-Reply-To: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> References: <049.ab105c92fe831dbeb2a865399ed587a3@haskell.org> Message-ID: <064.4eafdbace5cbb6e7f35edcc093812ef2@haskell.org> #9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | numeric/should_run/T9407 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rdragon): Replying to [comment:10 rwbarton]: > If someone would care to test 7.10.1 and 7.6 on Windows, I would be curious to know the results. I tested with GHC 7.6.3 and 7.10.1 on Windows 64bit. The issue was already present in 7.6.3 (I got the wrong output), but was already fixed in 7.10.1. Looks like a different bug, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 08:40:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 08:40:02 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.af8f2ca6184fd11727f61c79ddb2dd62@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This is missing the stderr file, I see this on travis: {{{ Actual stderr output differs from expected: --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ ./polykinds/T11466.comp.stderr.normalised 2016-01-21 22:52:43.864816991 +0000 @@ -0,0 +1,6 @@ + +T11466.hs:15:10: + Illegal implicit parameter ????x::Int??? + In the context: Bla + While checking an instance declaration + In the instance declaration for ???Eq T??? \ No newline at end of file *** unexpected failure for T11466(normal) }}} https://s3.amazonaws.com/archive.travis-ci.org/jobs/103959091/log.txt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 09:36:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 09:36:05 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.f3ec3b54208670f6632106fd79f7742c@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.0.1 Comment: This is something we should try to sort out before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 09:46:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 09:46:41 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.e9bc56da2ee2c76caa87cea5893b3f72@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: high => normal * milestone: 8.0.1 => Comment: comment:2 does indeed suggest a special case. I'll implement that. Your original example seems to work in HEAD. I'll try the current 8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 09:49:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 09:49:10 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.e2988f984ce6e3173480c441a239c567@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Correct: can someone just add the .stderr file. Sorry about that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 09:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 09:50:40 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.22b68430f91d6e4dc038281178a448c9@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"36b174df5433b217b4178da59917766e663337e7/ghc" 36b174d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="36b174df5433b217b4178da59917766e663337e7" Add expected stderr for #11466 test case }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 09:50:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 09:50:53 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.359f7134c276471d24ceca364e474fd1@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Correct: can someone just add the .stderr file. Sorry about that. ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 09:54:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 09:54:42 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.cddf5db352fc63c4068a643a75e439a8@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => SafeHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:02:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:02:24 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.7e476384a39bc93ad3eaa758b782698a@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by nomeata): > A counting indirection sounds like the right kind of thing. Looking a bit into this `IND_COUNTING` now; so I?ll go into ?dumping notes into trac? mode, for the future benefit of me or whoever else continues. There is already a closure type `IND_PERM` which is not removed by the GC; our counting indirections requires the same behavior. So this is a good start, I guess. The following comments are observations from looking at every mention of `IND_PERM` in the code. * `Cmm.h` has macros to `ENTER` a closure, which shortcuts indirections without calling their entry code. This is not what we want for an `IND_COUNTING`; so we should use the `default` code there, to actually enter the counting closure. * Should the interpreter also count entries? I don?t see any reference to `ticky` in `Interpreter.c`, so probably not. * Should `rts/Stable.c` preserve `IND_COUNTING`? It does not preserve `IND_PERM`, so probably not. * Fun fact: tricky and profiling do currently not mix. As I plan to do this counting as part of ticky, this means I can ignore problems with profiling in the RTS (the closures still have to work, of course). * `scavenge_mark_stack` does nothing for `IND_PERM` with a comment I don?t fully understand. Will revisit. Weird. I only find lots of code that ''handles'' `IND_PERM`, but none that actually creates closures of that type. Is all that dead code, likely since 2010?s reimplementation of BLACHOLES by Simon Marlow? (changeset:5d52d9b/ghc) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:20:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:20:10 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.340bfc7883a193c2fca5ee786c60a46c@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -2,2 +2,6 @@ - main = forever $ threadDelay 1000000 >> return () . - + {{{#!hs + import Control.Concurrent + import Control.Monad (forever) + main :: IO () + main = forever $ threadDelay 1000000 >> return () + }}} @@ -7,1 +11,1 @@ - a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. + a 2Ghz machine). Running with `+RTS -I0`, so this is not the idle gc. @@ -12,1 +16,1 @@ - I see I can switch off "master tick interval" with -V0, and then CPU is + I see I can switch off "master tick interval" with `-V0`, and then CPU is @@ -17,1 +21,1 @@ - platform, 64bit), it doesn't use more CPU than the non-profiling. + platform, 64-bit), it doesn't use more CPU than the non-profiling. New description: The program is {{{#!hs import Control.Concurrent import Control.Monad (forever) main :: IO () main = forever $ threadDelay 1000000 >> return () }}} Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with `+RTS -I0`, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with `-V0`, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64-bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Comment (by bgamari): If I'm not mistaken this is an expected result of our profiler, which is a sampling profiler. Looking at a `perf` profile reveals that this CPU time is largely spent in `handle_tick`. Diving in here we find that the first thing this function does is call `handleProfTick`, which does a variety of book-keeping to schedule the next time/heap sample. There is yet another difference, however: in the non-profiling case the tick timer is stopped when the process is known to be idle. In the profiling case we can't do this, to ensure that our profile isn't skewed. However, I believe it would be safe to nevertheless disable the compiler if you didn't run the executable with `+RTS -h` or `+RTS -p`. This is probably something that we should do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:22:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:22:48 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.b9751eb62c54f62c459710b86403c211@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by nomeata): Created Phab:D1821 to let Harbormaster check if `IND_PERM` is really unused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:23:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:23:05 -0000 Subject: [GHC] #8782: Using GADT's to maintain invariant in GHC libraries In-Reply-To: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> References: <051.0debe67dd751a3c93df7d7d89ad247db@haskell.org> Message-ID: <066.9123c569043c74dd79b29297c23ae97f@haskell.org> #8782: Using GADT's to maintain invariant in GHC libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 7.9 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 thomie): * owner: => Iceland_jack Comment: Iceland_jack: what is the status? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:25:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:25:35 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.8f7430ac85230019e7dd9b6eeb0c2650@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1822 Comment: See Phab:D1822 for a proposed fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:26:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:26:56 -0000 Subject: [GHC] #8772: ghci should save history more often In-Reply-To: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> References: <046.7de96bdd9c1f26a5cddbf4d5489fb344@haskell.org> Message-ID: <061.948a1c695a654fef2f4d842dc9a4e6f5@haskell.org> #8772: ghci should save history more often -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * component: Core Libraries => GHCi Comment: For a newcomer: first do https://github.com/judah/haskeline/issues/5, then come back here to modify GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:35:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:35:56 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.89ed7b2d7d1b116afed7ffb2ad93ec6c@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: simonmar => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 10:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 10:46:30 -0000 Subject: [GHC] #8875: Track Exceptions In-Reply-To: <044.40ee9daff1e997b21df30175182c507b@haskell.org> References: <044.40ee9daff1e997b21df30175182c507b@haskell.org> Message-ID: <059.177d55a666a38d8636cd8956b94931e6@haskell.org> #8875: Track Exceptions -------------------------------------+------------------------------------- Reporter: yokto | Owner: Type: feature request | 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 bgamari): While you might be able to track this for synchronous exceptions, tracking asynchronous exceptions would be nearly impossible given that anyone might throw you anything at any time. Even if you are okay with this limitation, identifying which exceptions a function might throw is a non-trivial task which would require some sort of inter-procedure analysis, especially when you account for the fact that an exception handler may dynamically choose not to handle a given exception. To make matters worse, the only exception handling constructs that the compiler currently knows about are `throw#` and `catch#` (and some variants), which know nothing of exception types (they merely expect some boxed Haskell value, which is typically a `SomeException` which packages an exception value together with a `Typeable` dictionary so we can reconstruct the type later). So, while it might be possible to implement some approximation of what is requested here, it doesn't seem to me like the complexity of such an implementation would pull its wait. Moreover, you can get much of what you have requested in the type system, either by encoding errors in the result type of your computation or some other encoding of checked exceptions (e.g. http://www.well-typed.com/blog/2015/07/checked-exceptions/). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 11:01:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 11:01:04 -0000 Subject: [GHC] #8666: integer-gmp fails to compile on Debian Squeeze In-Reply-To: <048.8db85b43ef2d1468096db30170850312@haskell.org> References: <048.8db85b43ef2d1468096db30170850312@haskell.org> Message-ID: <063.ae627aa08b0221f634995719e058394b@haskell.org> #8666: integer-gmp fails to compile on Debian Squeeze -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.7 Resolution: | Keywords: integer-gmp Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => integer-gmp * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 11:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 11:47:24 -0000 Subject: [GHC] #8907: Un-zonked kind variable passes through type checker In-Reply-To: <047.8d583b99a10a02d33fcf9e56e368fd06@haskell.org> References: <047.8d583b99a10a02d33fcf9e56e368fd06@haskell.org> Message-ID: <062.8a900cd44a23234ab1be8e1ba7de835a@haskell.org> #8907: Un-zonked kind variable passes through type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.1-rc2 checker) | 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 goldfire): * status: new => closed * resolution: => fixed Comment: Yes, this would appear to be fixed. Thanks for noticing! Not worth a regression test, as I don't think the old behavior actually caused any problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 11:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 11:53:12 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.a4eec6fb2fc81dff606571c490bc098f@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: #11449, #11451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Re comment:16: But your two wildcards are referring to the same type. I think we should require a name here, because the name is actually used twice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 11:58:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 11:58:16 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.4fc9e76e102b89babf0b3ab343bb1e0f@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I retract comment:7. I have no idea what I was thinking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 12:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 12:01:16 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.d18ad9bfce5132d7b4ee7f9dc0519922@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms 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): Yes. I think all of these should work, modulo parsing. (I'm worried about `(@ a)` instead of `@a`. Would need to test to be sure.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 12:23:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 12:23:01 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.b2bcd34b12ebd33c6ff1150afc451750@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Comment: Indeed, we really shouldn't release with `hpc` being broken, even if it is just with type applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 12:25:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 12:25:45 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.bec880f84c73b873a36e233c1fb1fc67@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1809 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as e6bbaefcf7d0aa9ce5d6845cf82329e473fd88c0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 12:28:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 12:28:09 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.754e944883474f19e51a4d32aee9482c@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, indeed I did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 12:55:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 12:55:00 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.b10b9f65579c1082177e872ddf51dae0@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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:D1656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * milestone: 8.0.1 => 8.2.1 Comment: I suppose is isn't urgent for 8.0, but I really would like to get to the bottom of these seg-faults. So I'll make it "highest" for 8.2. Ben may find time to investigate, but perhaps someone else could? It's a very specific change so it should not be hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:20:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:20: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.ab9f30047669ceb5ad79e7bdc92e722c@haskell.org> #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"835a2a24a605f8e458f57c71aa67e9983593b5e4/ghc" 835a2a24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="835a2a24a605f8e458f57c71aa67e9983593b5e4" Default non-canonical CallStack constraints Test Plan: `make test TEST=T11462` Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1804 GHC Trac Issues: #11462 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:20:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:20:12 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.0aa098e14fe740981092119f396418c6@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2df422161bccf7c0fad97e468085ebab1a17e19e/ghc" 2df42216/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2df422161bccf7c0fad97e468085ebab1a17e19e" Add tests for #11465 and the kind invariant }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:22:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:22:00 -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.805aeb0e2eb8f7f9b9fd3b561f6fd73d@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) | Resolution: fixed | Keywords: 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 bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` in 38dc961bf8459577b8a57d5e04a90b470c79fe0c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:30:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:30:57 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.c7ff0917e80e3d72b6ecb81aa6072778@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): rwbarton, the testcase is already attached (attachment:InstanceSerialize.hs). Your assessment sounds about right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:32:06 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.3514359529e28ae41f6607a725effde2@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Comment (by bgamari): Is there anyone who could test Phab:D1704? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:32:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:32:12 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.093a614ecc4184b37ad086136e962782@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:33:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:33:35 -0000 Subject: [GHC] #11260: Re-compilation driver/recomp11 test fails In-Reply-To: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> References: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> Message-ID: <062.d09bdcaaadf981628e26df9e1b71140d@haskell.org> #11260: Re-compilation driver/recomp11 test fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Right, I've not observed failures of `recomp015`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 13:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 13:35:41 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.7fc976e0732045aace6c6cecd39dc04f@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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:D1447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: RyanGlScott (added) Comment: Adding RyanGlScott who has done some great work with generics recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 14:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 14:29:47 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.9497ec66a17637c036b0a2370b265802@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by simonmar): Why not emit some update code into a single entry thunk that updates the thunk with something that will explode if it is entered again? That seems a lot easier than allocating indirctions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 14:42:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 14:42:15 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.9891230a9edd0c5ab53cbdd9c64702a4@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by nomeata): > Why not emit some update code into a single entry thunk that updates the thunk with something that will explode if it is entered again? That seems a lot easier than allocating indirctions. Right, that would be sufficient to detect thunks that are wrongly marked single-entry. But we also want to learn about thunks that are ''not'' marked single-entry, but should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 14:46:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 14:46:53 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.46e4210107d4a8f0953fab13f9d5363a@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): In Phab:D1618, which removes `IND_PERM`, simonmar wrote that the functionality removed there might be needed to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 14:47:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 14:47:32 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.05e9558b65339c1abb617fc733b450d9@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by simonmar): > Right, that would be sufficient to detect thunks that are wrongly marked single-entry. But we also want to learn about thunks that are not marked single-entry, but should be. Do you expect to learn much by doing that? We know the analysis is inaccurate, and I expect you'll just find a lot of thunks that are used a long way from the definition site. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 14:56:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 14:56:24 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.b127cf37ddad848feadccbf88b0a7560@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: #11449, #11451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:17 goldfire]: > Re comment:16: But your two wildcards are referring to the same type. I think we should require a name here, because the name is actually used twice. I suppose if we take interpret every occurrence of `_` as a fresh type variable, then the `Either a _` in the instance head cannot be the same as the one in the associated type family instance. And there's even another reason to require named type variables: what about `-XInstanceSigs`? If you allowed wildcards in instances, you could have a scenario like this: {{{#!hs class C a where c :: a -> String instance C (Maybe _) where c :: Maybe _ -> String c _ = "huh?" }}} And we certainly don't allow wildcards in term-level type signatures like this. In light of this, I retract my objection in comment:16. As Simon said, the description of the ticket is still right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 14:59:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 14:59:40 -0000 Subject: [GHC] #11478: ghc -e shouldn't print "Loaded GHCi configuration" message In-Reply-To: <047.ab61d3400307177855148860dc3d1387@haskell.org> References: <047.ab61d3400307177855148860dc3d1387@haskell.org> Message-ID: <062.4812d94a931fbc7162ff4d08ac17be04@haskell.org> #11478: ghc -e shouldn't print "Loaded GHCi configuration" message -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1817 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"9048c3dfee1c7c9171114c349714095b3abcc47a/ghc" 9048c3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9048c3dfee1c7c9171114c349714095b3abcc47a" Don't print "Loaded GHCi configuration" message in ghc -e (#11478) Summary: Also don't print it if the user specifically requested non-verbose output with -v0. Since this means there is no longer any test that checks for the message, add such a test. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1817 GHC Trac Issues: #11478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 15:07:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 15:07:18 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.671b3b3d5a4cb073db90bbe86c0a03af@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Never mind, I don't think things like {{{#!hs instance C [_] where type T [_] = Int }}} should be allowed after all (see [https://ghc.haskell.org/trac/ghc/ticket/11450#comment:18 my comment] in #11450 for rationale). That being said, I don't know if we should rule out putting wildcards in class instances altogether. Typeclasses without associated type families or methods wouldn't have the issue of requiring the types to be the same, so you could conceivably have something like this: {{{#!hs class C a where instance C _ where }}} Although I don't know how useful this is. And I really don't know how to feel about things like `data T _ = T` or `class C a _`, since we'd be allowing wildcards in place of `TyVar`s, which is uncharted territory. Neither are Haskell98 for sure, so I agree that if we allow such a thing, you should need a language extension to turn it on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 15:12:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 15:12:53 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.2dea843947197172bfda8fc8ff86e3e2@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: This turned out to be a problem in `uniplate`. I submitted a pull request here: https://github.com/ndmitchell/uniplate/pull/15. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 15:34:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 15:34:11 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.bcf5b2a3b6d4645eef3012b1e48c3812@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): From the pull request: > To be honest, I don't understand in detail why my patch fixes it. Why do you think it's a bug in uniplate and not in ghc? Perhaps the change you propose simply avoid the ghc bug that is still there? (I haven't studied the patch carefully, but it looks somewhat cryptic.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 15:38:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 15:38:15 -0000 Subject: [GHC] #8605: Alternative, guard-like syntax for view patterns In-Reply-To: <045.1743f62a4b303ec17137487f24324e6f@haskell.org> References: <045.1743f62a4b303ec17137487f24324e6f@haskell.org> Message-ID: <060.19cc63a4e868cd595af3c8fdc346d246@haskell.org> #8605: Alternative, guard-like syntax for view patterns -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | 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 thomie): * This ticket was created in reponse to this thread: https://mail.haskell.org/pipermail/ghc-devs/2013-December/003447.html. * And Simon mentions in https://mail.haskell.org/pipermail/ghc- devs/2014-June/005266.html "I'd really like to replace view patterns with [wiki:ViewPatternsAlternative]". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 15:42:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 15:42:41 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.c57c4c07a9557aba12e451141cff8a99@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'd be willing to implement this, but let me make sure I understand what's being proposed. My understanding is that: * `-Wunused-matches` should no longer warn about unused type variables. Instead, a different flag (I propose `-Wunused-type-variables`) should trigger this separately. * `-Wunused-type-variables` shouldn't be enabled when `-Wall` is on. (Do we want a `-pedantic` flag which implies `-Wunused-type-variables`?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 15:44:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 15:44:47 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.c2e5220012465acbf08d346835ae3966@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): What is cryptic about it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:03:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:03:01 -0000 Subject: [GHC] #11056: Need to generate Typable info for promoted data constructors In-Reply-To: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> References: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> Message-ID: <061.0d5d908f9d52426e27de54b3f96a2273@haskell.org> #11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1823 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:15:12 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.16db2dd5868511351b5cd7826fa449f2@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes we expect to learn a lot. From a scientific point of view (and writing the journal paper) I'm very interested to know how many of the single-entry thunks are found by the analysis. Let's say there are N thunk allocation sites in the code. We find that 15% are single-entry. If we found that only 20% were entered once (that 15% plus another 5%) that would mean there was at most another 5% that a more sophisticated analysis might find. But the number might be much larger. If the number is large, we might start to characterise the missed opportunities further. Perhaps some are being missed because of a bug in the analysis. Others might be caught by a simple improvement in the analysis. That's the thinking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:22:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:22:47 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.419e529e79cc0c453adab6e80d197512@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So in an expression like `print @Double 3` the type argument is getting a tick, so that the ticked expression looks like `tick print (tick @Double) (tick 3)`. Then `dsExpr`'s `HsApp` case no longer recognizes the construction `tick print (tick @Double)` as a type application, due to the second `tick`, and later tries and fails to desugar the argument `@Double`. One solution would be to look through ticks in `isLHsTypeExpr`, so that `dsExpr`'s `HsApp` case would still recognize a type application even if there are ticks in it. That would be simple and the type argument is then thrown away at that point anyways. But maybe it's better not to introduce a tick around a type argument in the first place, since that makes no sense. `Coverage.addTickHsExpr` has a case {{{ addTickHsExpr e@(HsTypeOut _) = return e }}} but it doesn't work as intended because `addTickHsExpr` only controls what ticks are added to the body of an expression. Whether to add a tick around the whole expression is controlled by `addTickLHsExpr` and a number of similar functions. I'm building a fix that recognizes type applications in `addTickHsExpr` and will post it on Phab when ready. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:23:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:23:19 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.c354687a3fa88f7a995d198f33acd68d@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): From compiler/specialise/SpecConstr.hs: {{{ Note [Forcing specialisation] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With stream fusion and in other similar cases, we want to fully specialise some (but not necessarily all!) loops regardless of their size and the number of specialisations. We allow a library to do this, in one of two ways (one which is deprecated): 1) Add a parameter of type GHC.Types.SPEC (from ghc-prim) to the loop body. 2) (Deprecated) Annotate a type with ForceSpecConstr from GHC.Exts, and then add *that* type as a parameter to the loop body The reason #2 is deprecated is because it requires GHCi, which isn't available for things like a cross compiler using stage1. }}} So it goes something like this: * uniplate used `ForceSpecConstr` somewhere * `ForceSpecConstr` requires GHCi to run * since ghc-7.8, GHCi requires shared libraries to be built * `shared:false` disables building shared libraries * error I changed `uniplate` to use `GHC.Types.SPEC` instead of `ForceSpecConstr`, as suggested by that `Note`. I don't think I am covering up a bug in GHC here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:34:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:34:24 -0000 Subject: [GHC] #8586: internal error: evacuate(static): strange closure type 5189 In-Reply-To: <044.1c644f7f58d3cc3b77a418e4f5a65979@haskell.org> References: <044.1c644f7f58d3cc3b77a418e4f5a65979@haskell.org> Message-ID: <059.6b7e07bdf4b4cb98f997e0f17191bbc1@haskell.org> #8586: internal error: evacuate(static): strange closure type 5189 -------------------------------+------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: crash Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Sorry about that! Windows has seen lots of bug fixes lately, so hopefully this one has been fixed as well. If you see that message again, or any other panic, please open a new ticket. I'm closing this one, as it was filed again a release which is no longer supported, and there doesn't seem to be a reliable way to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:38:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:38:42 -0000 Subject: [GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp In-Reply-To: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> References: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> Message-ID: <059.bc708ebb618bf8426ad5106bea340765@haskell.org> #8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: integer-gmp 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 thomie): * keywords: => integer-gmp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:41:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:41:25 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.54f750e3f9fde1425b4bcab55ef2a0ba@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Sorry, I pasted the first example after I removed the `UndecidableInstances` from the code. With that turned on it spins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:44:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:44:44 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.eae759ca8a502fb6f5ccd113eb352f8d@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Now this is very clear, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:49:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:49:34 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.830dacbdb1b064d7ffbd1e625f2cf2e7@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D1824 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 16:53:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 16:53:41 -0000 Subject: [GHC] #8618: can't load .so/.DLL In-Reply-To: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> References: <048.2735393b0fb36a2447e9e970e62e9258@haskell.org> Message-ID: <063.406dd888a1eb194de3ad71a25222e38b@haskell.org> #8618: can't load .so/.DLL -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Linking) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Thanks for keeping me honest :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:15:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:15:00 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.69a22742afc72d68f02700d93a32888f@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah! Correct. I have nailed it. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:40:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:40:28 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.07f31964c14e1f23e6c803f98ed650d8@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1825 Comment: A first shot at fixing this is Phab:D1825. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:49:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:49:06 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.11ca13e04b972ea47b593a8023df196a@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4d51bfc8975f9c6c3ab6d293c48f98da85210d5f/ghc" 4d51bfc8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d51bfc8975f9c6c3ab6d293c48f98da85210d5f" Do not count void arguments when considering a function for loopification. This fixes #11372 by omitting arguments with a void-type when checking whether a self-recursive tail call can be optimized to a local jump. Previously, a function taking a real argument and a State# token would report an arity of 1 in the SelfLoopInfo in getCallMethod, but a self-recursive call would apply it to 2 arguments, one of them being the State# token, thus no local jump would be generated. As the State# token is not represented by anything at runtime, we can ignore it and thus trigger the loopification optimization. Test Plan: ./validate Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1767 GHC Trac Issues: #11372 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:49:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:49:06 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.be6105be1d7156924bb166ce81464a70@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b01288d509b0f9e45f23ae48f2366f85f489089c/ghc" b01288d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b01288d509b0f9e45f23ae48f2366f85f489089c" rts: Disable tick timer unless really needed Trac #9105 notes significant CPU usage by an otherwise idle process when compiled with profiling. The reason for this is that we keep the tick timer active in the profiling RTS even if profiling wasn't requested at runtime. If the user requests any sort of profiling then we need to keep the timer active to ensure that samples are collected. Test Plan: Validate, check CPU usage, ensure profiling still works Reviewers: simonmar, austin Reviewed By: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1822 GHC Trac Issues: #9105 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:49:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:49:51 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.87a60dc60b69073ef1b928868bc29f4c@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:50:27 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.2359906aa35c2d1e74a6e903c2354ff2@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 17:50:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 17:50:33 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.72824d70b202a1519c5e3576342c00ae@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 18:10:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 18:10:00 -0000 Subject: [GHC] #11468: testsuite should ignore config files In-Reply-To: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> References: <049.de2320dee7569d2d6851ff576589c50b@haskell.org> Message-ID: <064.461caba1ac73dbef53e4b688157a9fda@haskell.org> #11468: testsuite should ignore config files -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.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 thomie): Replying to [comment:3 rwbarton]: > We could factor out all this repetition, though. How about a variable `TEST_HC_INTERACTIVE_OPTS` that is set to `$(TEST_HC_OPTS) --interactive -ignore-dot-ghci -v0`? Good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 18:25:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 18:25:23 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.99b8a1d1656f5f387e2cf492dcc17357@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): It does actually, assuming you mean replacing `show` by `id` in the ticket. `GHCi.UI.Info.processAllTypeCheckedModule` is trying to desugar all the spans in the typechecked program individually to find out their types. One of those spans is `@Int`, which can't be desugared outside of the context `show @Int`. We should skip such subexpressions: any `HsTypeOut` constructor. Since this code is written in Generics-ese, I don't feel like trying to fix it myself. (Also, surely there is a more sensible way to collect this data then desugaring every span to find out its type, when we have already type checked the whole module?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 18:42:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 18:42:42 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.29ef5ae329ed91cc4121a5e1df4b3153@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications 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 rwbarton): * cc: goldfire (added) Comment: In general, though, this is a trap for GHC API users, who might expect every `HsExpr` to be, well, an expression. Richard, did you consider representing explicit type applications with a separate constructor `HsTypeApp`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 18:57:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 18:57:48 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.d8825e0df31f6a80e53b48ee3aecdce3@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Specifically, leave `Parser.y` unchanged, but at the end of parsing, convert all `HsApp e (HsType t)` to `HsTypeApp e t` (modulo locations, etc.) Then there are no invariants of the form "`HsType` can appear only within `HsApp`", just ones of the form "the output of [stage X] cannot contain [constructor Y]". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 22 20:18:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jan 2016 20:18:28 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.2107c7da102d95a97be102cf9d2f0cef@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I've been bit by this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 12:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 12:28:55 -0000 Subject: [GHC] #8422: type nats solver is too weak! In-Reply-To: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> References: <045.a8bed5de254996d75b3b1116e9b1eced@haskell.org> Message-ID: <060.9bbf88eb23610137b153dcdf35e26364@haskell.org> #8422: type nats solver is too weak! -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: TypeLits 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 thomie): * keywords: => TypeLits @@ -5,0 +5,24 @@ + + {{{#!hs + {-# LANGUAGE DataKinds #-} + {-# LANGUAGE GADTs #-} + {-# LANGUAGE KindSignatures #-} + {-# LANGUAGE TypeOperators #-} + module Fancy where + + import GHC.TypeLits + + infixr 3 :* + + data Shape (rank :: Nat) where + Nil :: Shape 0 + (:*) :: {-# UNPACK #-} !(Int :: *) -> !(Shape r) -> Shape (1 + r) + + reverseShape :: Shape r -> Shape r + reverseShape Nil = Nil + reverseShape shs = go shs Nil + where + go :: Shape a -> Shape b -> Shape (a+b) + go Nil res = res + go (ix :* more ) res = go more (ix :* res) + }}} New description: I just built ghc HEAD today, and the type nat solver can't handle the attached program, which *should* be simple to check! (and while I could use unsafeCoerce to "prove" it correct, that defeats the purpose of having the type nat solver!) {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} module Fancy where import GHC.TypeLits infixr 3 :* data Shape (rank :: Nat) where Nil :: Shape 0 (:*) :: {-# UNPACK #-} !(Int :: *) -> !(Shape r) -> Shape (1 + r) reverseShape :: Shape r -> Shape r reverseShape Nil = Nil reverseShape shs = go shs Nil where go :: Shape a -> Shape b -> Shape (a+b) go Nil res = res go (ix :* more ) res = go more (ix :* res) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 12:43:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 12:43:03 -0000 Subject: [GHC] #11056: Need to generate Typable info for promoted data constructors In-Reply-To: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> References: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> Message-ID: <061.17339143f70a8fc8d8e3ae4b5f5954bc@haskell.org> #11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1823 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4e04043d1bb458439d3c3db3ffa9851bff780083/ghc" 4e04043d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4e04043d1bb458439d3c3db3ffa9851bff780083" Add test for Trac #11056 Reviewers: thomie, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton Differential Revision: https://phabricator.haskell.org/D1823 GHC Trac Issues: #11056 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 12:43:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 12:43:03 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.70f68b2d1ca2e988445cae161e8e981e@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f42db1574935b088cfc13cca7c935990002651dc/ghc" f42db157/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f42db1574935b088cfc13cca7c935990002651dc" Remove unused IND_PERM it seems that this closure type has not been in use since 5d52d9, so all this is dead and untested code. This removes it. Some of the code might be useful for a counting indirection as described in #10613, so when implementing that, have a look at what this commit removes. Test Plan: validate on harbormaster Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1821 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 13:32:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 13:32:12 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes Message-ID: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.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: -------------------------------------+------------------------------------- Test.hs: {{{#!hs f :: Int f = _ main = print f }}} {{{ $ ghc-8.0.1 --interactive GHCi, version 8.0.0.20160111: http://www.haskell.org/ghc/ :? for help Prelude> :load! Test.hs [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:2:5: error: ? Found hole: _ :: Int ? In the expression: _ In an equation for ?f?: f = _ ? Relevant bindings include f :: Int (bound at Test.hs:2:1) Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 13:34:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 13:34:17 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.902bc292047ceac5200325e57f2c954b@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9497 Comment: triple: this makes `:load!` and `:reload!` rather less useful. Do you think you could fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 13:34:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 13:34:19 -0000 Subject: [GHC] #11056: Need to generate Typable info for promoted data constructors In-Reply-To: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> References: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> Message-ID: <061.f959c6e94eb2cae5a62ec86054f48cd0@haskell.org> #11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 14:25:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 14:25:00 -0000 Subject: [GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible In-Reply-To: <045.1992743c6be5a313d344284f20ce0d35@haskell.org> References: <045.1992743c6be5a313d344284f20ce0d35@haskell.org> Message-ID: <060.ab3a7001c6f2a750273224cab7db5132@haskell.org> #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 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 rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 14:30:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 14:30:39 -0000 Subject: [GHC] #11482: Turn -fdefer-typed-holes on by default Message-ID: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> #11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9497, #11481 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they?re easy to detect during a production build.? That's terrible, they should be using typed holes! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which does always show a warning (unless explicitly suppressed). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 14:36:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 14:36:42 -0000 Subject: [GHC] #8064: Warning out when "undefined" value has been used. In-Reply-To: <045.11abfb7ee2328a943f0e43d8bb3d3c78@haskell.org> References: <045.11abfb7ee2328a943f0e43d8bb3d3c78@haskell.org> Message-ID: <060.8599cf32604c5b288fe30543f70c7940@haskell.org> #8064: Warning out when "undefined" value has been used. -------------------------------------+------------------------------------- Reporter: freizl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 thomie): * status: new => closed * resolution: => wontfix Comment: It's much better to use [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- holes.html typed holes] instead of `undefined` for this purpose, since it will give you the warning you requested. {{{#!hs f :: Int f = _ main = print f }}} {{{ $ ghc-7.10.3 -fdefer-typed-holes Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:2:5: Warning: Found hole ?_? with type: Int Relevant bindings include f :: Int (bound at Test.hs:2:1) In the expression: _ In an equation for ?f?: f = _ Linking Test ... }}} To suppress the warning, use `-fno-warn-typed-holes`. Given that these flags now exist, I'm closing this as wontfix. See #11482 for a request to turn `-fdefer-typed-holes` on by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 14:40:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 14:40:21 -0000 Subject: [GHC] #11482: Turn -fdefer-typed-holes on by default In-Reply-To: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> References: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> Message-ID: <060.b2a5b63b07d29e0d426edb01339b1a2e@haskell.org> #11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by thomie: @@ -8,1 +8,3 @@ - That's terrible, they should be using typed holes! + That's terrible, they should be using + [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- + holes.html typed holes]! @@ -22,3 +24,3 @@ - use typed holes, which does always show a warning (unless explicitly - suppressed). Having to specify a command-line flag is too high a barrier - (since `undefined` is so well known and easy to use) + use typed holes, which does show a warning (unless explicitly suppressed + with `-fno-warn-typed-holes`). Having to specify a command-line flag is + too high a barrier (since `undefined` is so well known and easy to use) New description: From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they?re easy to detect during a production build.? That's terrible, they should be using [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- holes.html typed holes]! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which does show a warning (unless explicitly suppressed with `-fno-warn-typed-holes`). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 14:42:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 14:42:29 -0000 Subject: [GHC] #11482: Turn -fdefer-typed-holes on by default In-Reply-To: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> References: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> Message-ID: <060.6eaae8fd932b357076921befd0f1238a@haskell.org> #11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Incorrect warning at compile-time @@ -24,1 +24,1 @@ - use typed holes, which does show a warning (unless explicitly suppressed + use typed holes, which do show a warning (unless explicitly suppressed New description: From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they?re easy to detect during a production build.? That's terrible, they should be using [https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/typed- holes.html typed holes]! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which do show a warning (unless explicitly suppressed with `-fno-warn-typed-holes`). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:23:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:23:33 -0000 Subject: [GHC] #11482: Turn -fdefer-typed-holes on by default In-Reply-To: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> References: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> Message-ID: <060.c30b79bb767f217a281e9fd5ec0161c2@haskell.org> #11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You make a good point. What about this design alternative: * ghc turns `-fdefer-typed-holes` on by default * Cabal / stack use `-fno-defer-typed-holes` by default. * We encourage everyone to use `_` instead of `undefined`. * If the type of a typed hole is known (that is, "pushed in", in the sense of bidirectional type-checking) we emit a very short, one line warning instead of the longer one with types. Even better, we could common up all of these warnings into one that says where the holes are. This design depends somewhat on what standard workflows are. (I have no clue about standard workflows, as I'm quite non-standard.) Do people use cabal/stack right from the get-go when starting a project? Or do they prototype in GHCi a bit before making a build structure? If it's the latter, then the design above makes sense. If it's the former, not so much. I also think the last point would be a nice part of this. The idea is that if you say {{{#!hs frooble :: Bool frooble = _ -- not sure if we're froobling today }}} we don't need a long-form warning telling us that the hole has type `Bool`. A short warning saying `hole at (...)` is enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:25:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:25:52 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.4caecef42677bf08139619d62fb8f60d@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by triple): * owner: => triple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:27:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:27:51 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.ff69164437934fb7090694505333c398@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: fixed => Comment: Commit [changeset:"9915b6564403a6d17651e9969e9ea5d7d7e78e7f/ghc" 9915b656/ghc] broke the tests that had been fixed in [changeset:"28638dfe79e915f33d75a1b22c5adce9e2b62b97/ghc" 28638df/ghc] again, namely: {{{ make slowtest TEST='exceptionsrun001 T3279 conc012 conc014' }}} (Note that the ways that broke, including optasm, are not run by validate by default.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:29:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:29:39 -0000 Subject: [GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible In-Reply-To: <045.1992743c6be5a313d344284f20ce0d35@haskell.org> References: <045.1992743c6be5a313d344284f20ce0d35@haskell.org> Message-ID: <060.26c487c07ca559a8ef80fcc1abf5cc82@haskell.org> #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 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 really like this general idea but I have some minor quibbles in the details. I propose this behavior when compiling a line of code in GHCi: * Start with the baseline !DynFlags * Apply flags specified on the original command-line * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * If there is a fully-open module M, apply flags specified in M itself. * Apply flags specified by :set in this GHCi session. * Apply flags specified by :seti in this GHCi session The idea is that if a user asks GHCi for a behavior, the user should get that behavior, regardless of any open modules. With the originally proposed order, it would be impossible to countermand a choice made in the fully open module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:44:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:44:18 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.a06ffe139380d3a06fb194180c1811b6@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications 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: | -------------------------------------+------------------------------------- Comment (by goldfire): No, I didn't consider `HsTypeApp`. That would probably be an improvement. My choice of abstract syntax was inspired by Core, which just has `App :: CoreExpr -> CoreExpr -> CoreExpr` and `Type :: Type -> CoreExpr`. I'll look into this refactoring. It could actually simplify quite a bit. (For example, see the awful `tcSeq` and `tcTagToEnum` in !TcExpr.) Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:46:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:46:55 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.d38d65b2f96973b134f4433d761399d5@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I thought `-Wunused-type-variables` could be on with `-Wall`. But we just won't warn in situations where the type variable could appear in documentation. And then (optional extension for extra credit) we'd have a separate `-Wpedantic-unused-type-variables` that warned in all cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:49:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:49:20 -0000 Subject: [GHC] #8403: Pretty-printing of long types In-Reply-To: <047.792ac96369079bc46b579fe906221406@haskell.org> References: <047.792ac96369079bc46b579fe906221406@haskell.org> Message-ID: <062.dec9cad3d640f6d0f9b30a49a5ebd228@haskell.org> #8403: Pretty-printing of long types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #9428 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: See comment:4. Please reopen if you //really// want this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 15:55:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 15:55:00 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.b4e9ebdad44d299eb65c8219b770de04@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm confused. Under what scenarios would type variables in instances ''not'' appear as documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 16:38:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 16:38:02 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.23dcaf3dc97bee6076e56a792f4d63d8@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by jscholl): I have a theory what is happening here: The important values here are {{{arr2}}} and some value called {{{get}}}. In the original definition {{{get}}} evaluates {{{arr2}}} and uses some component of it. Now {{{arr2}}} just is some tuple type ({{{ADelayed}}}) with two lazy fields. It is constructed by evaluating another value {{{arr}}} and then building this tuple. The second field of the tuple is just a thunk. So the simplifier inlines {{{arr2}}} in {{{get}}} and thus avoids building the tuple thing of {{{arr2}}}. Now the last reference to {{{arr2}}} was dropped. In the next run the simplifier replaces {{{arr2}}} with {{{absentError}}}. Shortly after that a reference to {{{arr2}}} appears again in the code. So what went wrong? {{{get}}} had an unfolding! In this unfolding it mentions {{{arr2}}} and the simplifier spots a position where it wants to inline {{{get}}}. Now we have a reference to {{{arr2}}} again because the unoptimized version of {{{get}}} is inlined. But this time we will optimize in a different way as {{{arr2}}} was incorrectly changed to {{{absentError}}}. So the main question would be: Does the compiler consider unfoldings when determining whether a value is unused and thus can be replaced by {{{absentError}}}? If not this could be the culprit. Sadly the bug relies on a very specific order of events in the compiler, so it will be hard to find a smaller test case for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 16:44:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 16:44:08 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.14cf38cebbdd52d407827a1c571084f1@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by thomie): pally: I can not reproduce your problem. Which platform are you on? And how long does it take before your program crashes? Here's what I tried: * I'm using Ubuntu 14.04 Linux, x86-64. * I installed the following packages, after some trial and error: `libfftw3-dev libopenal-dev qtchooser qtbase5-dev qtdeclarative5-dev qtdeclarative5-qtquick2-plugin darcs` * `cabal sandbox init` * `darcs get http://hub.darcs.net/pallly/hdur` * `darcs get http://hub.darcs.net/komadori/HsQML` * `cabal install HsQML/` * `cabal install hdur/` * `.cabal-sandbox/bin/hdur` # Fails with some module not found error (frustrating! please fix, cabal install should have caught that) * I then installed `qml-module-qtquick2` from 15.04 (vivid). This also upgrade most other qt related packages * `.cabal-sandbox/bin/hdur` * I see a grey window with the subtext "foobar". When I press 'o', a black squiggly line appears on a white background. * No crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 17:16:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 17:16:25 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.2 In-Reply-To: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> References: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> Message-ID: <061.be38e9bad747ad7941b71771a3decc33@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): rwbarton astutely points out that `MIN_VERSION_GLASGOW_HASKELL`, which is used in the above commit (which was merged to `ghc-8.0` as well), was only introduced in ghc 7.10. Looks like we'll need to revert to `__GLASGOW_HASKELL__` in `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 17:26:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 17:26:53 -0000 Subject: [GHC] #11483: Ghci integration with readline Message-ID: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> #11483: Ghci integration with readline -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: readline | Operating System: Unknown/Multiple complete | Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When running ghci, the word "import" is not in the list generated by readline completion. Namely, if to type {{{#!hs > i }}} the suggestions that appear after pressing are {{{#!hs id isDenormalized isNegativeZero init isIEEE iterate interact isInfinite ioError isNaN }}} If to type {{{#!hs > im }}} then pressing gives beep. Also, if we have at prompt {{{#!hs > import q }}} pressing does not produce any completion. I would expect to get {{{#!hs > import qualified }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 17:38:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 17:38:17 -0000 Subject: [GHC] #11483: Ghci integration with readline In-Reply-To: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> References: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> Message-ID: <058.9fb705127998aaa254597eb5abfa0999@haskell.org> #11483: Ghci integration with readline -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Geraldus Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: readline | complete Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10576 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => Geraldus * related: => #10576 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 18:31:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 18:31:12 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler In-Reply-To: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> References: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> Message-ID: <061.141d6a4f866589fbe263e191ba36d109@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8308, #9405 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling * related: => #8308, #9405 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 18:32:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 18:32:05 -0000 Subject: [GHC] #8325: Pattern guards in anonymous functions In-Reply-To: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> References: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> Message-ID: <061.d6877c94708421e7e2d35a84c73e97e6@haskell.org> #8325: Pattern guards in anonymous functions -------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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 rwbarton): One tricky case would be trying to write something like {{{ f z | odd z = \x y | x > y -> x | otherwise -> y | even z = \x y -> 0 }}} The `| even z` guard has to be attached to `f` because it is followed by `=`, but that requires some look-ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 18:42:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 18:42:16 -0000 Subject: [GHC] #8325: Pattern guards in anonymous functions In-Reply-To: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> References: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> Message-ID: <061.c0c42ed020c10cbfb414c45983bcefe9@haskell.org> #8325: Pattern guards in anonymous functions -------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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 goldfire): `MultiWayIf` uses layout to fix this ambiguity, essentially requiring all the `|` to line up. I find this a bit annoying (but don't have a better idea), because I want to say {{{ if | blah -> blah | blah -> blah }}} which is disallowed. Instead, I need to indent the arrows. In any case, the layout approach should work for lambdas, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 18:46:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 18:46:33 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.32d2ef304f587f7d1434c2caa51de855@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): In a type signature in a term-level pattern, I suppose. But I agree that maybe there aren't enough places like this to motivate separating out the behavior. I guess you're design is closer to the spec than I thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 18:58:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 18:58:49 -0000 Subject: [GHC] #8325: Pattern guards in anonymous functions In-Reply-To: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> References: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> Message-ID: <061.f7b38d73a2f0a1eb5d9614d33955d1b7@haskell.org> #8325: Pattern guards in anonymous functions -------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7783, #10807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #7783, #10807 Comment: As pointed out in #10807, you can use curly braces: {{{ {-# LANGUAGE MultiWayIf #-} x = if { | True -> 1 | False -> 2 } }}} `MultiWayIf` was changed to use layout in #7783. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 19:07:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 19:07:35 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.00a69d5621b386f3388e0acc03edc523@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One open question here is how this should interact with #10632, which requests warnings for unused implicit parameters. This was addressed with `-Wredundant-constraints`, which we are now disabling by default. Is it reasonable to expect users to enable `-Wredundant-constraints` to be warned of unused implicit parameters? Implicit parameters "feel" a lot more like arguments than constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 19:08:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 19:08:19 -0000 Subject: [GHC] #10632: ImplicitParams: GHC does not warn about unused implicit parameters In-Reply-To: <043.e43a281629468e7ea1a3cf04b358b377@haskell.org> References: <043.e43a281629468e7ea1a3cf04b358b377@haskell.org> Message-ID: <058.a7e1018a794c378c884f72027ec480c7@haskell.org> #10632: ImplicitParams: GHC does not warn about unused implicit parameters -------------------------------------+------------------------------------- Reporter: mwnx | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): We may need to disable these warnings by default (including with `-Wall`). See #11370 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:27:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:27:09 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.a12772c0a6b60317244542ee8cf9aec0@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: feature request | Status: patch Priority: highest | Milestone: 8.0.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:D1830 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1830 Comment: Implementation in Phab:D1830. Note that this flag is order dependent. That is, {{{ ghc -Wfoobar -Wno-unrecognised-warning-flag }}} will throw a warning but {{{ ghc -Wno-unrecognised-warning-flag -Wfoobar }}} will not. This, however, is already true of existing flags (e.g. see #10560). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:28:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:28:06 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.978ba2a8c728787f1ee2c7f1c03cb4d5@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8e9a87025f954a2704850bc71cb497f768d5d595/ghc" 8e9a870/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e9a87025f954a2704850bc71cb497f768d5d595" Remove -Wredundant-superclasses from standard warnings It is impossible to write warning-free code under the three-release policy with this flag enabled by default. See #11370 for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:29:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:29:28 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.7541d8285d6af12c9a4806c369038b3a@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"ec8778862aeb9c3f6b861bc732045db9f58b9b61/ghc" ec877886/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec8778862aeb9c3f6b861bc732045db9f58b9b61" Don't add ticks around type applications (#11329) Test Plan: validate --slow Reviewers: austin, bgamari, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1824 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:31:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:31:16 -0000 Subject: [GHC] #8325: Pattern guards in anonymous functions In-Reply-To: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> References: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> Message-ID: <061.9d19c4b186e43a26de9d60438650c014@haskell.org> #8325: Pattern guards in anonymous functions -------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7783, #10807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not very familiar with the implementation of `MultiWayIf`, but having `if` introduce layout seems more palatable than having an arbitrary "last variable of lambda" do so... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:32:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:32:01 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.6bec5f2d5a3bd55d2c18b371f11f0932@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge Comment: Resolved with 8e9a87025f954a2704850bc71cb497f768d5d595. Needs merging to `ghc-8.0`. Handling of unrecognised warnings (#11429) is implemented in Phab:D1830. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:47:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:47:04 -0000 Subject: [GHC] #3990: UNPACK doesn't unbox data families In-Reply-To: <041.50e84dc9fb16fae63af270459584532c@haskell.org> References: <041.50e84dc9fb16fae63af270459584532c@haskell.org> Message-ID: <056.7909538b588f51c2899b20b71655b1ed@haskell.org> #3990: UNPACK doesn't unbox data families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.0.3 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): If it possible that the fix in comment:13 has broken? I am seeing no evidence of unpacking in this example with `master`, {{{#!hs {-# LANGUAGE TypeFamilies #-} module Hi where data family Complex a data instance Complex Double = CD {-# UNPACK #-} !Double {-# UNPACK #-} !Double data T = T {-# UNPACK #-} !(Complex Double) hi :: T hi = T (CD 1 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:47:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:47:19 -0000 Subject: [GHC] #3990: UNPACK doesn't unbox data families In-Reply-To: <041.50e84dc9fb16fae63af270459584532c@haskell.org> References: <041.50e84dc9fb16fae63af270459584532c@haskell.org> Message-ID: <056.5769c335dec58091e5365c7d6e800b62@haskell.org> #3990: UNPACK doesn't unbox data families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.0.3 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 bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 20:51:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 20:51:48 -0000 Subject: [GHC] #7650: can't use combining characters in identifiers In-Reply-To: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> References: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> Message-ID: <059.7304e25eeea32337fa353f900050a406@haskell.org> #7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.2 (Parser) | Resolution: | Keywords: unicode 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: hvr (added) Comment: Here is an example of the sort of Unicode questions that would be nice to fix in Haskell'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:30:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:30:08 -0000 Subject: [GHC] #7608: LLVM only handles a hard-coded list of triples. In-Reply-To: <049.5e6798700ded89ff697ada495d9b6a1a@haskell.org> References: <049.5e6798700ded89ff697ada495d9b6a1a@haskell.org> Message-ID: <064.7f10bf9adc782fbe803016c3cc409019@haskell.org> #7608: LLVM only handles a hard-coded list of triples. -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.7 Resolution: wontfix | Keywords: cross- | compiling llvm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 7610 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: As far as I can tell this isn't a bug. As far as I know there is no way to avoid enumerating supported triplets like this. For instance, `rustc` has a [[https://github.com/vhbit/rust/blob/b94bb8766ee952812309a4d542e86401f6d6048e/src/librustc_back/target/i386_apple_ios.rs|very similar table]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:38:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:38:14 -0000 Subject: [GHC] #11478: ghc -e shouldn't print "Loaded GHCi configuration" message In-Reply-To: <047.ab61d3400307177855148860dc3d1387@haskell.org> References: <047.ab61d3400307177855148860dc3d1387@haskell.org> Message-ID: <062.28efa237cb3a1aa3d6e63e908e84ef67@haskell.org> #11478: ghc -e shouldn't print "Loaded GHCi configuration" message -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:45:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:45:03 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.390542a8d420bdd72d7530701c553dad@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If someone is going to add class-specific pragmas, making `UndecidableSuperClasses` work on a per-class (rather than per-module) basis would be good. What would this look like? Any class in the cycle being marked with the pragma would allow undecidable superclasses? If we are going to do this we may want to consider doing it before the 8.0 release. Moving from per-module to per-class modules after the per-class pragmas are in the wild may be rather painful (judging by the move from `OverlappingInstances` to `{-# OVERLAPPING #-}`, although perhaps `UndecidableSuperClasses` won't see as wide use). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:48:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:48:45 -0000 Subject: [GHC] #5641: The -L flag should not exist In-Reply-To: <047.46e72104686b8a69940a4b2fea73bf01@haskell.org> References: <047.46e72104686b8a69940a4b2fea73bf01@haskell.org> Message-ID: <062.7c74bf07628d7e5c99e9df2e5087d949@haskell.org> #5641: The -L flag should not exist -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3024 | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"923d2151db261cac36577bcaffa6be41c3f374f9/ghc" 923d215/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="923d2151db261cac36577bcaffa6be41c3f374f9" user-guide: Document -L RTS flag See #5641. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:48:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:48:45 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.7f65515f5ee1b45406beb3fb09c5997f@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"89bdac7635e6ed08927d760aa885d3e7ef3edb81/ghc" 89bdac7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89bdac7635e6ed08927d760aa885d3e7ef3edb81" Add test for #11473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:59:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:59:02 -0000 Subject: [GHC] #11484: Type synonym using -XTypeInType can't be spliced with TH Message-ID: <050.31117dc14e8cb137c4aa49635eca3d7d@haskell.org> #11484: Type synonym using -XTypeInType can't be spliced with TH -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc1 Haskell | 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: -------------------------------------+------------------------------------- The following code compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -ddump-splices #-} module Foo where import Data.Kind type TySyn (k :: *) (a :: k) = () -- $([d| type TySyn2 (k :: *) (a :: k) = () |]) }}} But uncomment the last line, and it doesn't compile: {{{ $ /opt/ghc/head/bin/ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:10:3-43: Splicing declarations [d| type TySyn2_aBH (k_aBI :: *) (a_aBJ :: k_aBI) = () |] ======> type TySyn2_a4BF (k_a4BG :: Type) (a_a4BH :: k_a4BG) = () Foo.hs:10:3: error: ? Couldn't match expected kind ?GHC.Prim.Any? with actual kind ?k1? ? In the type declaration for ?TySyn2? Foo.hs:10:3: error: ? Kind variable ?k_a4BG? is implicitly bound in datatype ?TySyn2?, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: k_a4BG (a_a4BH :: GHC.Prim.Any) ? In the type declaration for ?TySyn2? }}} There are two issues here: 1. The error message claims that `TySyn2` is a datatype when it is actually a type synonym. This should be easy enough to fix; just change [http://git.haskell.org/ghc.git/blob/89bdac7635e6ed08927d760aa885d3e7ef3edb81:/compiler/typecheck/TcHsType.hs#l1874 the code] that throws the error message to invoke [http://git.haskell.org/ghc.git/blob/89bdac7635e6ed08927d760aa885d3e7ef3edb81:/compiler/types/TyCon.hs#l1957 tyConFlavour]. 2. For some reason, the type variable `a` in `TySyn2` fails to kind-check. Somehow, an `Any` got in there, but I'm not sure where it snuck in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 21:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 21:59:27 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.de14b89542ac961432ae36983bb3cb6e@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 Comment: So I guess there are no objections to moving ahead with this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 22:08:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 22:08:04 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.4a7ad1e2c83d04dfdaa58224f0e5b64d@haskell.org> #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #7867 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) Comment: errge, it seems that this was dropped yet again; I'm sorry that this process has been so messy. Would you like to rebase your patches and put them up on Phabricator? There we can do a proper review. I'm also cc'ing goldfire, who is our Template Haskell czar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 22:41:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 22:41:57 -0000 Subject: [GHC] #11212: Should be more liberal parsing pattern synonyms with view patterns In-Reply-To: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> References: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> Message-ID: <064.628eb2a78d9cc57a0dc5b84b96c7a9d7@haskell.org> #11212: Should be more liberal parsing pattern synonyms with view patterns -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: Resolution: | PatternSynonyms 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 thomie): With `-XMultiWayIf`, `if | Just True <- Just True -> True` is a valid expression. It looks similar to the example in this ticket: two arrows in opposite directions, no parenthesis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 23:03:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 23:03:38 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.f772614c8ab525c25bcd70f1399a2780@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've thought of a simpler spec still * If a type variable bound by an explicit, user-written `forall` is unused, we warn. * But it it is bound only by a type pattern (in a class or type instance declaration), we don't warn even if it is otherwise unused. That's nice and precise. I'm agnostic about what flags control this. I suppose you might want to say A. No warnings at all B. Warn about unused `forall`-bound variables C. Warn about those and unused pattern-bound variables (maybe) It's not clear that implementing C is worth it. (Yes that's what we currently have, more or less, but inconsistently.) I don't have a strong opinion about what flags should switch between A and B, or A/B/C. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 23:05:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 23:05:57 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.cb0fd3173a9acfce4059e77bda3f8294@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What would this look like? Any class in the cycle being marked with the pragma would allow undecidable superclasses? This issue is when we report a class cycle. If any class in the cycle has a "UndecidableSuperClasses" pragma, then yes, I suggest we do not warn. It'd be great to put this per-class stuff in 8.0, but someone would have to step up and implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 23:13:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 23:13:02 -0000 Subject: [GHC] #8285: unexpected behavior with encodeFloat on large inputs In-Reply-To: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> References: <045.f7eaecd94e96f3fd291d7a1c2d15ebef@haskell.org> Message-ID: <060.5c90c33804f5600bc5ae6486d9453bf0@haskell.org> #8285: unexpected behavior with encodeFloat on large inputs -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 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: | -------------------------------------+------------------------------------- @@ -1,1 +1,3 @@ - benjamin scarlet discovered some unexpected behavior in encodeFloat today + {{{ + > encodeFloat 1 1023 + 8.98846567431158e307 -- ok @@ -3,3 +5,2 @@ - {{{ - > map (\x -> encodeFloat 1 (shiftL 1 x)) [30,31] - [23:47:47] [Infinity,0.0] + > encodeFloat 1 1024 + Infinity -- ok @@ -7,2 +8,2 @@ - [23:49:09] > encodeFloat 1 60 - [23:49:10] 1.152921504606847e18 + > encodeFloat 1 (2^31 - 1) + Infinity -- ok @@ -10,16 +11,2 @@ - [23:49:09] > encodeFloat 1 60 - [23:49:10] 1.152921504606847e18 - [23:49:18] er. - [23:50:21] down in the sane range I suspect it's just fine. - [23:50:43] > encodeFloat 1 1000 - [23:50:44] 1.0715086071862673e301 - [23:50:52] > encodeFloat 1 10000 - [23:50:53] Infinity - [23:50:58] That's sane. - [23:51:03] > encodeFloat 1 (2^31) - [23:51:04] 0.0 - [23:51:13] That's what I think is weird. - [23:51:19] bscarlet floats are weird - [23:51:23] > encodeFloat 1 (2^31-1) - [23:51:24] Infinity - + > encodeFloat 1 (2^31) + 0.0 -- not ok @@ -27,6 +14,0 @@ - Benjamin did a wee bit of investigation, and the - problem seems to lie in https://github.com/ghc/packages-integer- - gmp/blob/master/cbits/float.c#L177 - in integer-gmp, where it deliberately doesn't handle the edge cases - (probably worth investigating) if integer-simple has similar behavior or - not New description: {{{ > encodeFloat 1 1023 8.98846567431158e307 -- ok > encodeFloat 1 1024 Infinity -- ok > encodeFloat 1 (2^31 - 1) Infinity -- ok > encodeFloat 1 (2^31) 0.0 -- not ok }}} -- Comment (by thomie): I think this just needs an update to the `encodeFloat` docstring. To confirms what hvr said in comment:2: test.c: {{{ #include #include #include #include #include #include void test(double x, int exp) { errno = 0; feclearexcept(FE_ALL_EXCEPT); printf("(%f)*2^(%d) = %f\n", x, exp, ldexp(x, exp)); printf("errno: %d (ERANGE = %d), UNDERFLOW: %d, OVERFLOW: %d\n", errno, ERANGE, fetestexcept(FE_UNDERFLOW) == FE_UNDERFLOW, fetestexcept(FE_OVERFLOW) == FE_OVERFLOW); } void main() { // If the result overflows, a range error occurs, and the functions // return HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively, with a sign // the same as x. test(1, 1024); test(1, INT_MAX); // 2^31 - 1 printf("\n"); // If the result underflows, a range error occurs, and zero is // returned. test(1, DBL_MIN_EXP); // Not sure why not getting range error here, test(1, -1074); // or here. test(1, -1075); // but only starting here. test(1, 1 << 31); printf("\n"); // If x is positive infinity (negative infinity), positive infinity // (negative infinity) is returned. test(HUGE_VAL, 1 << 31); test(- HUGE_VAL, 1 << 31); } }}} {{{ $ gcc test.c -lm $ ./a.out (1.000000)*2^(1024) = inf errno: 34 (ERANGE = 34), UNDERFLOW: 0, OVERFLOW: 1 (1.000000)*2^(2147483647) = inf errno: 34 (ERANGE = 34), UNDERFLOW: 0, OVERFLOW: 1 (1.000000)*2^(-1021) = 0.000000 errno: 0 (ERANGE = 34), UNDERFLOW: 0, OVERFLOW: 0 (1.000000)*2^(-1074) = 0.000000 errno: 0 (ERANGE = 34), UNDERFLOW: 0, OVERFLOW: 0 (1.000000)*2^(-1075) = 0.000000 errno: 34 (ERANGE = 34), UNDERFLOW: 1, OVERFLOW: 0 (1.000000)*2^(-2147483648) = 0.000000 errno: 34 (ERANGE = 34), UNDERFLOW: 1, OVERFLOW: 0 (inf)*2^(-2147483648) = inf errno: 0 (ERANGE = 34), UNDERFLOW: 0, OVERFLOW: 0 (-inf)*2^(-2147483648) = -inf errno: 0 (ERANGE = 34), UNDERFLOW: 0, OVERFLOW: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 23:20:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 23:20:03 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.8c924b88cfcc32c87a0cc3e7fa2deea8@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, I believe we will have precisely what you described with Phab:D1825. `-Wname-shadowing` controls unused `forall`-ed type variables, and `Wtype-variables` controls unused type patterns separately. You can enable different combinations of them to achieve A, B, and C. The only remaining question is if we want a single flag that implies C (my previous name suggestion was `-pedantic`). This would be pretty easy to implement if we wanted it, since it would just enable a superset of the flags implied by `-Wall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 23:52:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 23:52:25 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e327ce3e0308174c87f6d7298fc41a44@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 23 23:56:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jan 2016 23:56:44 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.954bfa667337274c2c8b7912c3335416@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Changes (by triple): * differential: => Phab:D1833 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 00:20:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 00:20:57 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.32d20afc33576940ebe34cb609a46325@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sorry, I'm wrong, it's also `-Wunused-matches` which warns about unused quantified type variables. Do you think it's worth having two separate flags for warning about term-level patterns vs. quantified type variables? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 04:26:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 04:26:50 -0000 Subject: [GHC] #11485: Very unhelpful message resulting from kind mismatch Message-ID: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> #11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code: {{{#!hs module Foo where import Data.Typeable tyConOf :: Typeable a => Proxy a -> TyCon tyConOf = typeRepTyCon . typeRep tcList :: TyCon tcList = tyConOf (Proxy :: Proxy []) }}} fails because `-XPolyKinds` is not enabled. But the error message that you get is quite different on GHC 7.10 and 8.0. On GHC 7.10.3: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:9:19: Couldn't match kind ?* -> *? with ?*? Expected type: Proxy a0 Actual type: Proxy [] In the first argument of ?tyConOf?, namely ?(Proxy :: Proxy [])? In the expression: tyConOf (Proxy :: Proxy []) In an equation for ?tcList?: tcList = tyConOf (Proxy :: Proxy []) }}} But on GHC 8.0.1-rc1: {{{ Foo.hs:9:19: error: ? Expected kind ?Proxy []?, but ?Data.Proxy.Proxy :: Proxy []? has kind ?Proxy []? ? In the first argument of ?tyConOf?, namely ?(Proxy :: Proxy [])? In the expression: tyConOf (Proxy :: Proxy []) In an equation for ?tcList?: tcList = tyConOf (Proxy :: Proxy []) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 06:34:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 06:34:21 -0000 Subject: [GHC] #11486: info tables are no longer aligned Message-ID: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Take a simple program like {{{ main = mapM_ print "Hello, world" }}} and build with `-O`. Versions of ghc as late as 7.11.20150806 generate assembly that includes {{{ ... _c3mn: movq $sat_s3m2_info,-16(%r12) movq %r14,(%r12) movq $block_c3mi_info,-16(%rbp) movl $GHC.Types.True_closure+2,%edi movq %rsi,%rax leaq -16(%r12),%rsi movl $GHC.IO.Handle.FD.stdout_closure,%r14d movq %rax,-8(%rbp) addq $-16,%rbp jmp GHC.IO.Handle.Text.hPutStr2_info .text .align 8 .quad 1 .quad 32 block_c3mi_info: _c3mi: movq 8(%rbp),%rbx addq $16,%rbp jmp stg_ap_v_fast ... }}} Note the `.align 8` ensuring that the info table (and the code `_c3mi` itself) is 8-byte aligned. In 8.1.20160107 we instead get {{{ _c5gE: movq $sat_s5g9_info,-16(%r12) movq %r14,(%r12) movq $block_c5gz_info,-16(%rbp) movl $GHC.Types.True_closure+2,%edi movq %rsi,%rax leaq -16(%r12),%rsi movl $GHC.IO.Handle.FD.stdout_closure,%r14d movq %rax,-8(%rbp) addq $-16,%rbp jmp GHC.IO.Handle.Text.hPutStr2_info _c5gF: movq $24,904(%r13) _c5gC: movl $Main.main2_closure,%ebx jmp *-8(%r13) .quad 1 .quad 32 block_c5gz_info: _c5gz: movq 8(%rbp),%rbx addq $16,%rbp jmp stg_ap_v_fast .size Main.main2_info, .-Main.main2_info }}} There is some minor rearrangement, but more importantly there is no longer any `.align 8` before `.quad 1`. That means the info table is not necessarily aligned, and indeed `c5gz_info` ended up at the address `40676f`. I'm guessing this is bad for performance, though I don't know how bad. I'm pretty sure this is due to 4a32bf925b8aba7885d9c745769fe84a10979a53 "Implement function-sections for Haskell code" though I haven't looked at that commit in detail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 09:20:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 09:20:27 -0000 Subject: [GHC] Batch modify: #3711, #8997, #9244, #9376, #9456, #9672, #9755, ... Message-ID: <20160124092027.D28243A2FF@ghc.haskell.org> Batch modification to #3711, #8997, #9244, #9376, #9456, #9672, #9755, #11219, #11427, #11438 by thomie: failure to Incorrect warning at compile-time -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 09:25:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 09:25:50 -0000 Subject: [GHC] Batch modify: #8634, #8673, #8707, #8828, #9118, #9123, #9267, ... Message-ID: <20160124092550.DE2173A2FF@ghc.haskell.org> Batch modification to #8634, #8673, #8707, #8828, #9118, #9123, #9267, #9269, #9450, #9627, #9918, #11197, #11198, #11203, #11207, #11213, #11333 by thomie: component to Compiler (Type checker) -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 09:32:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 09:32:02 -0000 Subject: [GHC] Batch modify: #8272, #8317, #8598, #8655, #8901, #8903, #8955, #10137 Message-ID: <20160124093202.CE6E43A2FF@ghc.haskell.org> Batch modification to #8272, #8317, #8598, #8655, #8901, #8903, #8955, #10137 by thomie: failure to Runtime performance bug -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 09:49:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 09:49:16 -0000 Subject: [GHC] #10783: Partial type signatures should work in pattern synonym signatures In-Reply-To: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> References: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> Message-ID: <064.521717a91be471e88608f5e0035f1385@haskell.org> #10783: Partial type signatures should work in pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PaternSynonyms partial-type- | signatures 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 thomie): * keywords: => PaternSynonyms partial-type-signatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 09:49:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 09:49:58 -0000 Subject: [GHC] #10783: Partial type signatures should work in pattern synonym signatures In-Reply-To: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> References: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> Message-ID: <064.0bd44c2c15dc0d797a0e005118eb11c2@haskell.org> #10783: Partial type signatures should work in pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms partial-type- | signatures 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 thomie): * keywords: PaternSynonyms partial-type-signatures => PatternSynonyms partial-type-signatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 10:10:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 10:10:43 -0000 Subject: [GHC] #10183: Warning for redundant constraints: interaction with pattern matching In-Reply-To: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> References: <046.02647e82b4059f07aa24c7e2e29b1e1f@haskell.org> Message-ID: <061.90d57aefb77350b12322c84b26d0d226@haskell.org> #10183: Warning for redundant constraints: interaction with pattern matching -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: redundant- | constraints, GADTs 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 thomie): * keywords: => redundant-constraints, GADTs * failure: None/Unknown => Incorrect warning at compile-time @@ -23,1 +23,1 @@ - Here's an example that doesn't depend on `TypeLits`: + Here's an example that only depends on `GADTs`: @@ -25,0 +25,1 @@ + {-# LANGUAGE GADTs #-} @@ -26,2 +27,2 @@ - TT :: T True - TF :: T False + TT :: T Bool + TF :: T Int @@ -29,1 +30,1 @@ - f :: T True -> Bool + f :: T Bool -> Bool @@ -32,1 +33,1 @@ - g :: (a ~ True) => T a -> Bool + g :: (a ~ Bool) => T a -> Bool @@ -37,1 +38,1 @@ - `(a~True)` is not used in the code for `g`. But that evidence is used to + `(a~Bool)` is not used in the code for `g`. But that evidence is used to New description: Herbert gives this example: {{{ {-# LANGUAGE GADTs, DataKinds, TypeOperators, UnicodeSyntax #-} import GHC.TypeLits data List l t where Nil ? List 0 t (:-) ? t ? List l t ? List (l+1) t head' ? (1<=l) ? List l t ? t head' (x :- _) = x }}} We get the warning {{{ typelits1.hs:9:9: Warning: Redundant constraint: 1 <= l In the type signature for: head' ? (1 <= l) ? List l t ? t }}} But of course the warning is not redundant if we want to exclude the `(head' Nil)` case. Here's an example that only depends on `GADTs`: {{{ {-# LANGUAGE GADTs #-} data T a where TT :: T Bool TF :: T Int f :: T Bool -> Bool f TT = True g :: (a ~ Bool) => T a -> Bool g TT = True }}} Here `f` compiles fine, but `g` warns about a redundant constraint, even though the two types are isomorphic! And indeed the evidence for `(a~Bool)` is not used in the code for `g`. But that evidence is used to prove that the un-matched pattern `(g TF)` is unreachable. I'm not sure how to fix this. Bother. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 10:21:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 10:21:08 -0000 Subject: [GHC] #10192: Template Haskell crashes when building yesod-core package In-Reply-To: <049.3323838842ade82bcaef02c773453e2b@haskell.org> References: <049.3323838842ade82bcaef02c773453e2b@haskell.org> Message-ID: <064.acc2c0e774d9525e27695866d7fac06d@haskell.org> #10192: Template Haskell crashes when building yesod-core package -------------------------------------+------------------------------------- Reporter: DanielDiaz | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: > I added "constraint: template-haskell installed" to my {{{~/.cabal/config}}} file and I built yesod-core successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 11:47:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 11:47:35 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.c320fff616b370dd2195182e9b4c526c@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | 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 rdragon): * owner: => rdragon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:06:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:06:54 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.bfb1785563ef65a1144ea35d15c57b5b@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Wiki Page: | Phab:D1562,Phab:D1747,Phab:D1748,Phab:D1836 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D1562,Phab:D1747,Phab:D1748 => Phab:D1562,Phab:D1747,Phab:D1748,Phab:D1836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:06:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:06:55 -0000 Subject: [GHC] #1158: Problem with GADTs and explicit type signatures In-Reply-To: <044.a690e5d82a359dfdcf39f6e9d5e20511@haskell.org> References: <044.a690e5d82a359dfdcf39f6e9d5e20511@haskell.org> Message-ID: <059.f18092e7a8fc50397912e03b15654808@haskell.org> #1158: Problem with GADTs and explicit type signatures -------------------------------------+------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: ? Component: Compiler (Type | Version: 6.6 checker) | Keywords: Resolution: | MultiParamTypeClasses, | AllowAmbiguousTypes 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 thomie): * keywords: => MultiParamTypeClasses, AllowAmbiguousTypes * component: Compiler => Compiler (Type checker) @@ -1,3 +1,5 @@ - {{{ - - {-# OPTIONS_GHC -fglasgow-exts #-} + {{{#!hs + {-# LANGUAGE GADTs #-} + {-# LANGUAGE MultiParamTypeClasses #-} + {-# LANGUAGE FlexibleInstances #-} + {-# LANGUAGE AllowAmbiguousTypes #-} @@ -25,1 +27,0 @@ - @@ -29,11 +30,15 @@ - test.hs:45:14: - Overlapping instances for LiftToExp a a11 - arising from use of `liftToExp' at test.hs:45:14-24 - Matching instances: - instance (Floating a) => LiftToExp a b -- Defined at test.hs:19:0 - instance LiftToExp (Exp a) a -- Defined at test.hs:16:0 - (The choice depends on the instantiation of `a, a11' - Use -fallow-incoherent-instances to use the first choice above) - In the first argument of `App', namely `(liftToExp x)' - In the expression: App (liftToExp x) - In the definition of `test': test x = App (liftToExp x) + Test.hs:48:15: error: + ? Overlapping instances for LiftToExp a a0 + arising from a use of ?liftToExp? + Matching givens (or their superclasses): + LiftToExp a a1 + bound by the type signature for: + test :: LiftToExp a a1 => a -> Exp b + at Test.hs:47:1-38 + Matching instances: + instance LiftToExp a b -- Defined at Test.hs:22:10 + instance LiftToExp (Exp a) a -- Defined at Test.hs:19:10 + (The choice depends on the instantiation of ?a, a0?) + ? In the first argument of ?App?, namely ?(liftToExp x)? + In the expression: App (liftToExp x) + In an equation for ?test?: test x = App (liftToExp x) @@ -42,4 +47,0 @@ - - Tested with GHC 6.6 (compiler and interpreter) under OS X 10.4.8 on an - iMac G5. - New description: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Main where data Exp a where Val :: a -> Exp b App :: Exp a -> Exp b instance Show (Exp a) where show (Val _) = "Val" show (App _) = "App" class LiftToExp a b where liftToExp :: a -> Exp b instance LiftToExp (Exp a) a where liftToExp = id instance Floating a => LiftToExp a b where liftToExp v = Val v :: Exp b {- Uncommenting the type signature below causes GHCi to fail to load the file: Test.hs:48:15: error: ? Overlapping instances for LiftToExp a a0 arising from a use of ?liftToExp? Matching givens (or their superclasses): LiftToExp a a1 bound by the type signature for: test :: LiftToExp a a1 => a -> Exp b at Test.hs:47:1-38 Matching instances: instance LiftToExp a b -- Defined at Test.hs:22:10 instance LiftToExp (Exp a) a -- Defined at Test.hs:19:10 (The choice depends on the instantiation of ?a, a0?) ? In the first argument of ?App?, namely ?(liftToExp x)? In the expression: App (liftToExp x) In an equation for ?test?: test x = App (liftToExp x) However typing :t test at the GHCi prompt gives this exact signature. -} --test :: (LiftToExp a a1) => a -> Exp b test x = App (liftToExp x) main = putStrLn $ show (test (3.0::Float)::Exp Int) }}} -- Comment: This example now requires `AllowAmbiguousTypes` (ghc-8.0.1). Is this still considered to be a bug, or are people who enable `AllowAmbiguousTypes` "asking for it"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:07:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:07:30 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.0f167af84e3fb536d568215ba13a0e98@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D1562,Phab:D1747,Phab:D1748,Phab:D1836 => Phab:D1562 Phab:D1747 Phab:D1748 Phab:D1836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:32:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:32:41 -0000 Subject: [GHC] #7521: Accelerate examples does not compile with default value of -fsimpl-tick-factor In-Reply-To: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> References: <046.a165b81ceec1b63f8c0bcb4e673ec08e@haskell.org> Message-ID: <061.afa8512cad2e08811304fd782aa7f7ff@haskell.org> #7521: Accelerate examples does not compile with default value of -fsimpl-tick- factor -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:15 bgamari]: > this ticket [...] arguably we could just close it. Yes, `-fsimpl-tick-factor=130` is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:35:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:35:00 -0000 Subject: [GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp In-Reply-To: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> References: <044.5aebbdf5a090b51634a7de92ab103ccd@haskell.org> Message-ID: <059.4cd6b36c8865be26f5ad845827666875@haskell.org> #8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.7 Resolution: | Keywords: integer-gmp 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 thomie): * component: Compiler => Profiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:54:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:54:03 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.008f5c6dd2edc97bd4d0fbe44a1f8973@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: #11330 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high Comment: Core lint errors are bad, raising priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 13:55:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 13:55:06 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.0dcf07fc7cde361f942d551b88356e2b@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.11 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 thomie): * component: Compiler => Compiler (LLVM) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:10:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:10:17 -0000 Subject: [GHC] Batch modify: #11486, #11383, #10626, #10346, #7307, #1168, #917 Message-ID: <20160124141017.151E23A2FF@ghc.haskell.org> Batch modification to #11486, #11383, #10626, #10346, #7307, #1168, #917 by thomie: failure to Runtime performance bug -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:19:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:19:28 -0000 Subject: [GHC] Batch modify: #11282, #11247, #9173, #8159, #4288, #4017 Message-ID: <20160124141928.64F693A2FF@ghc.haskell.org> Batch modification to #11282, #11247, #9173, #8159, #4288, #4017 by thomie: failure to Incorrect warning at compile-time -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:30:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:30:36 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.4d95e57868bfaf476bb28a7e144be4ee@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.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 thomie): * component: Compiler => Template Haskell Comment: Replying to [comment:7 owst]: > Yes, I agree I am, I will try to suggest some edits. Feel free to just post them here in a comment. Someone else can polish it and put it in the user's guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:31:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:31:53 -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.1f0cab42beb58ba51e8361ba2f466db9@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 thomie): * type: bug => task Comment: Seems like this is just a refactoring task, not a user facing bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:37:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:37:31 -0000 Subject: [GHC] Batch modify: #5777, #7828, #9985, #5267, #5333, #344 Message-ID: <20160124143731.AECBA3A2FF@ghc.haskell.org> Batch modification to #5777, #7828, #9985, #5267, #5333, #344 by thomie: keywords to Arrows component to Compiler (Type checker) -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:45:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:45:07 -0000 Subject: [GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals In-Reply-To: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> References: <045.aa22727e9338664a3617f731b2d178cd@haskell.org> Message-ID: <060.c58a0b92b2e206744ce10a318db59899@haskell.org> #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals -------------------------------------+------------------------------------- Reporter: oerjan | Owner: RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 (Parser) | Resolution: | Keywords: unicode 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:D1235 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => unicode -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 14:58:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 14:58:45 -0000 Subject: [GHC] #11306: Do not generate warning in `do` when result is of type `Void`. In-Reply-To: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> References: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> Message-ID: <062.c09d6a63a75a099fc1cdfa2445fb0d79@haskell.org> #11306: Do not generate warning in `do` when result is of type `Void`. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 thomie): * failure: None/Unknown => Incorrect warning at compile-time Comment: Won't fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 15:18:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 15:18:15 -0000 Subject: [GHC] Batch modify: #7828, #7845, #8671, #9883, #10381, #11216 Message-ID: <20160124151815.EAAC13A2FF@ghc.haskell.org> Batch modification to #7828, #7845, #8671, #9883, #10381, #11216 by thomie: keywords to RebindableSyntax -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 15:24:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 15:24:36 -0000 Subject: [GHC] #599: The Front Panel In-Reply-To: <047.879a405653c5eae0c010ebe545798cee@haskell.org> References: <047.879a405653c5eae0c010ebe545798cee@haskell.org> Message-ID: <062.9668f3fe61e96323b87234bb137f3144@haskell.org> #599: The Front Panel -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) * failure: => None/Unknown * status: new => closed * resolution: None => wontfix Comment: I don't think this "front panel" exists anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 15:45:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 15:45:30 -0000 Subject: [GHC] Batch modify: #855, #932, #7080, #7109, #8354, #9388, #11393, ... Message-ID: <20160124154530.3D6FE3A2FF@ghc.haskell.org> Batch modification to #855, #932, #7080, #7109, #8354, #9388, #11393, #11441, #4831, #5059, #9374 by thomie: failure to Runtime performance bug -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 15:58:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 15:58:14 -0000 Subject: [GHC] Batch modify: #5378, #7336, #8363, #9624, #9702, #10117, #10418, ... Message-ID: <20160124155814.072B73A2FF@ghc.haskell.org> Batch modification to #5378, #7336, #8363, #9624, #9702, #10117, #10418, #10930, #11066, #11418 by thomie: failure to Incorrect warning at compile-time -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 16:10:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 16:10:50 -0000 Subject: [GHC] Batch modify: #11451, #11429, #11370, #11369, #11309, #11270, ... Message-ID: <20160124161050.0FD943A2FF@ghc.haskell.org> Batch modification to #11451, #11429, #11370, #11369, #11309, #11270, #11221, #11099, #11091, #11006, #10913, #10752, #10150, #10116, #10089, #10071, #9756, #9678, #9573, #8944, #8872, #8012, #7169, #5813, #5288, #4980, #4959, #3283, #3085, #2522, #2365, #2135, #2119, #1628, #1318, #1308, #1231, #602 by thomie: failure to Incorrect warning at compile-time -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 16:26:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 16:26:28 -0000 Subject: [GHC] Batch modify: #3990, #5224, #8109, #8177, #8441, #9429, #9562, ... Message-ID: <20160124162628.1E2313A2FF@ghc.haskell.org> Batch modification to #3990, #5224, #8109, #8177, #8441, #9429, #9562, #9780, #10116, #10141, #10327, #10482, #10789, #10996, #11062, #11084, #11113, #11243, #11282, #11310, #11348, #11357, #2721, #4259, #8095, #8165, #8423, #9269, #9376, #9667, #9918, #10204, #10808, #10832, #10833, #11207, #11375, #11400, #11407, #11424, #7102, #9394, #7808 by thomie: keywords to TypeFamilies -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 16:38:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 16:38:29 -0000 Subject: [GHC] Batch modify: #2595, #9701, #11310, #345, #1158, #7494, #7503, ... Message-ID: <20160124163829.E70223A2FF@ghc.haskell.org> Batch modification to #2595, #9701, #11310, #345, #1158, #7494, #7503, #8128, #8560, #8673, #9456, #9667, #9985, #10617, #11145 by thomie: keywords to GADTs -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 17:00:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 17:00:43 -0000 Subject: [GHC] #8171: Extending ExtendedDefaultRules In-Reply-To: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> References: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> Message-ID: <060.9b3264cdf2ea20a759dacbc5587de614@haskell.org> #8171: Extending ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | ExtendedDefaultRules Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2641 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => ExtendedDefaultRules * related: => #2641 Comment: Replying to [comment:5 simonpj]: > The extended-default rules for a bunch of constraints (C1 a1, C2 a2, ...) are these: > 1. The type variable a appears in no other constraints > 2. All of the classes Ci are single-parameter type classes. > 3. At least one of the classes Ci is numeric, or is Show, Eq, or Ord. > > We could, I suppose, relax it by simply abolishing Rule 3. See also #2641 (still open), where you proposed to make these rules //less// liberal, albeit 7 years ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 17:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 17:01:55 -0000 Subject: [GHC] #2641: Revise the rules for -XExtendedDefaultRules In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@haskell.org> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@haskell.org> Message-ID: <061.96661daaacd875e77dcc162954c4c43f@haskell.org> #2641: Revise the rules for -XExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: | ExtendedDefaultRules Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8171 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => ExtendedDefaultRules * related: => #8171 Comment: See also #8171, where it is proposed to make the rules //more// liberal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 17:13:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 17:13:15 -0000 Subject: [GHC] Batch modify: #10826, #9562, #7634, #7635 Message-ID: <20160124171315.CA9C53A2FF@ghc.haskell.org> Batch modification to #10826, #9562, #7634, #7635 by thomie: keywords to SafeHaskell -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 18:07:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 18:07:57 -0000 Subject: [GHC] Batch modify: #624, #1016, #1216, #1330, #1349, #1365, #1377, ... Message-ID: <20160124180757.5550B3A2FF@ghc.haskell.org> Batch modification to #624, #1016, #1216, #1330, #1349, #1365, #1377, #1379, #1420, #1466, #1534, #1572, #1600, #1620, #1631, #1693, #1727, #1880, #1885, #1894, #1965, #2028, #2075, #2123, #2159, #2215, #2224, #2256, #2260, #2269, #2273, #2333, #2340, #2345, #2346, #2370, #2401, #2408, #2437, #2439, #2460, #2550, #2598, #2600, #2614, #2640, #2642, #2648, #2710, #2737, #2803, #2805, #2867, #2933, #2945, #2946, #2950, #2968, #2986, #3000, #3052, #3055, #3061, #3070, #3073, #3107, #3122, #3123, #3138, #3184, #3192, #3231, #3238, #3251, #3282, #3314, #3355, #3372, #3373, #3427, #3452, #3458, #3462, #3464, #3483, #3547, #3571, #3588, #3619, #3632, #3645, #3701, #3713, #3744, #3753, #3755, #3766, #3767, #3781, #3786, #3831, #3869, #3870, #3881, #3895, #3937, #3946, #3984, #4016, #4020, #4022, #4048, #4049, #4052, #4096, #4121, #4140, #4150, #4162, #4180, #4211, #4222, #4245, #4281, #4296, #4301, #4308, #4316, #4372, #4374, #4451, #4453, #4459, #4520, #4806, #4815, #4824, #4833, #4836, #489 9, #4900, #4913, #4942, #4955, #4960, #5016, #5073, #5075, #5140, #5142, #5143, #5171, #5197, #5218, #5219, #5266, #5291, #5298, #5302, #5305, #5320, #5326, #5392, #5444, #5539, #5556, #5590, #5619, #5620, #5645, #5672, #5761, #5786, #5791, #5823, #5902, #5910, #5918, #5927, #5954, #5985, #6017, #6040, #6087, #6107, #6113, #7044, #7048, #7063, #7066, #7078, #7081, #7104, #7105, #7140, #7141, #7152, #7158, #7198, #7204, #7240, #7246, #7283, #7296, #7297, #7300, #7320, #7331, #7335, #7337, #7373, #7374, #7380, #7388, #7395, #7398, #7401, #7413, #7430, #7443, #7461, #7495, #7511, #7535, #7539, #7543, #7593, #7606, #7610, #7611, #7624, #7625, #7637, #7665, #7668, #7670, #7679, #7687, #7741, #7779, #7789, #7803, #7829, #7836, #7849, #7930, #8014, #8036, #8107, #8198, #8226, #8252, #8287, #8288, #8321, #8323, #8362, #8398, #8429, #8457, #8460, #8489, #8623, #8657, #8694, #8695, #8732, #8733, #8751, #8922, #8971, #8981, #9020, #9046, #9133, #9274, #9307, #9352, #9358, #9405, #9596, #9649, #9671, #9717, #9719, #9743, #9786, #9795, #9797, #9806, #9841, #9982, #10189, #10217, #7482, #4937, #4385, #4470, #5692, #7542, #9251, #4413, #4823, #5495, #4081, #5522, #7190, #7437, #8144, #8303, #5959, #6047, #4176, #6132, #7428, #5262, #6092, #7114, #3606, #3980, #4102, #4329, #4442, #6101, #7045, #7285, #7353, #8767, #9631, #9674, #9716, #9792, #9908, #9022, #1574, #2776, #7181, #7644, #9247, #9248, #7259, #849, #7378, #5567, #1498, #4101, #8156, #2289, #2387, #2731, #3379, #10083, #7647, #3034, #5188, #5780, #5941, #7763, #8594, #8910, #9089, #2147, #1012, #10448, #8279, #8364, #3333, #4295, #9646, #10976, #7983, #5467, #8990, #7790, #8199, #6089, #7450, #7596, #5850, #7275, #609, #3559, #888, #6024, #7161, #9735, #9276, #781, #4945, #1544, #8731, #7258, #4092, #1290, #8581, #10301, #4114, #9614, #8761, #5615, #5834, #8238, #10046, #8396, #2258, #5972, #4479, #7492, #9821, #7459, #9043, #9453, #9526, #8176, #1853, #7277, #7414, #2168, #2189, #4105, #9289, #9342, #9353, #8763, #2940, #4243, #5642, #7245, #7655, #9237, #5928, #8258, #2374, #5987, #9034, #8827, #8782, #5654, #8422, #8406, #7650, #5641, #8426, #8285, #3711, #9123, #9267, #8272, #8572, #7307, #4017, #4288, #344, #5267, #5777, #7828, #5059, #7109, #5378, #602, #2119, #2135, #2365, #2522, #3085, #4959, #4980, #5288, #5813, #7169, #9573, #10071, #2721, #3990, #4259, #5224, #7808, #9780, #7494, #7503, #2641, #7635 by thomie: milestone to -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 18:26:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 18:26:07 -0000 Subject: [GHC] Batch modify: #10509, #10022, #10037, #10053, #10063, #10193, ... Message-ID: <20160124182607.3EDD43A2FF@ghc.haskell.org> Batch modification to #10509, #10022, #10037, #10053, #10063, #10193, #10594, #10701, #10702, #10707, #10823, #10909, #11050, #11078, #11161, #11297, #11366 by thomie: milestone to -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 18:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 18:34:35 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.f40b09a9d79823ee79dbacd69b2ee6c4@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | DuplicateRecordFields 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 thomie): * cc: adamgundry (added) * keywords: => DuplicateRecordFields * milestone: 8.0.1 => 8.2.1 Comment: Replying to [comment:1 hvr]: > I wonder if this is related to #11051 That bug is fixed, but this one is still present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 18:52:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 18:52:03 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.2adcf26ec2f39d7c8d77428dbb620c49@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 18:55:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 18:55:22 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.0d6b8cc2885d8dffd744c5874c1817c2@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Rev(s): Phab:D1130, #7666, #8809 | Phab:D1132 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.1 Comment: This is pretty much done. For parity with pretty-1.1.2.1 the following two commits would also be needed. I did not land them, because they seem to cause more allocation in the compiler (see discussion in ?https://github.com/haskell/pretty/pull/9): * "Resolve foldr-strictness stack overflow bug" * "Special-case reduce for horiz/vert" The commits are here: ?https://github.com/thomie/ghc/commits/pretty -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 19:32:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 19:32:46 -0000 Subject: [GHC] #9708: Type inference non-determinism due to improvement In-Reply-To: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> References: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> Message-ID: <061.e04a3f2113050f3bdfcaa1c85b383c95@haskell.org> #9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"2c6fe5b8a854f06ea9574f7dca545b4c2d35b811/ghc" 2c6fe5b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2c6fe5b8a854f06ea9574f7dca545b4c2d35b811" Add -fwarn-redundant-constrains to test for #9708 Fixes validate on Travis. Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1834 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 20:00:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:00:57 -0000 Subject: [GHC] #603: GC-spy connection In-Reply-To: <047.b54e7ec772620480fdaef37df77aff79@haskell.org> References: <047.b54e7ec772620480fdaef37df77aff79@haskell.org> Message-ID: <062.98e8c6094e8a19d571d8dc49e45d5c37@haskell.org> #603: GC-spy connection -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) * failure: => None/Unknown * status: new => closed * resolution: None => wontfix Comment: Given that the GC spy website doesn't even exist anymore, I think we can safely close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 20:12:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:12:01 -0000 Subject: [GHC] #603: GC-spy connection In-Reply-To: <047.b54e7ec772620480fdaef37df77aff79@haskell.org> References: <047.b54e7ec772620480fdaef37df77aff79@haskell.org> Message-ID: <062.f7512280649892b3ad66e1a9136cf680@haskell.org> #603: GC-spy connection -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): For future reference: http://www.cs.kent.ac.uk/projects/gc/gcspy/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 20:12:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:12:23 -0000 Subject: [GHC] #603: GC-spy connection In-Reply-To: <047.b54e7ec772620480fdaef37df77aff79@haskell.org> References: <047.b54e7ec772620480fdaef37df77aff79@haskell.org> Message-ID: <062.10a84acb2ff3f8da897b66406a519d15@haskell.org> #603: GC-spy connection -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by thomie: @@ -2,1 +2,1 @@ - [http://research.sun.com/projects/gcspy/ GC spy tool], which gives a + [http://www.cs.kent.ac.uk/projects/gc/gcspy/ GC spy tool], which gives a New description: Connect GHC's garbage collector to the [http://www.cs.kent.ac.uk/projects/gc/gcspy/ GC spy tool], which gives a graphical display of heap characteristics at runtime. (Similar to the Front Panel task: [ticket:599].) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 20:36:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:36:30 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.a83752d7c9fd30735cee3a511d7b3b6e@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by pallly): In the time of writing my first comment I was using Gentoo Linux, I have just managed to reproduce the problem using Arch Linux (synchronized today). Here is how I did it: * `cabal sandbox init` * `darcs get http://hub.darcs.net/pallly/hdur` * `darcs get http://hub.darcs.net/komadori/HsQML` * `cabal sandbox add-source HsQML/` * `cabal install hdur/ --enable-executable-profiling --enable-library- profiling` * `.cabal-sandbox/bin/hdur +RTS -hr` After spawning the last command the application mostly crashes within a second. If it doesn't, I press 'o' and then it always crashes within a second. Here's the message: {{{ hdur: internal error: Invalid object in isRetainer(): 8 (GHC version 7.10.3 for x86_64_unknown_linux) 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 Sun Jan 24 20:45:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:45:07 -0000 Subject: [GHC] #11150: New `-fwarn-noncanonical-monoid-instances` warning In-Reply-To: <042.55096ce3dad11d93367502f540669d4a@haskell.org> References: <042.55096ce3dad11d93367502f540669d4a@haskell.org> Message-ID: <057.da2e0baf27530815a97f223fcb224d8c@haskell.org> #11150: New `-fwarn-noncanonical-monoid-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11128, #11139 | Differential Rev(s): Phab:D1553 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"fd6dd41c67f3bd23bbf074357219cfd251eb53d6/ghc" fd6dd41c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd6dd41c67f3bd23bbf074357219cfd251eb53d6" Implement `-Wnoncanonical-monadfail-instances` warning The MonadFail proposal implemented so far via #10751 only warns about missing `MonadFail` instances based on existence of failible pattern matches in `do`-blocks. However, based on the noncanonical Monad warnings implemented via #11150 we can provide a different mechanism for detecting missing `MonadFail` instances quite cheaply. That is, by checking for canonical `fail` definitions. In the case of `Monad`/`MonadFail`, we define the canonical implementation of `fail` to be such that the soft-deprecated method shall (iff overridden) be defined in terms of the non-deprecated method. Consequently, in case of `MonadFail`, the `Monad(fail)` method shall be defined as alias of the `MonadFail(fail)` method. This allows us at some distant point in the future to remove `fail` from the `Monad` class, while having GHC ignore/tolerate such literal canonical method definitions. Reviewed By: bgamari, RyanGlScott Differential Revision: https://phabricator.haskell.org/D1838 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 20:45:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:45:08 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.86cb5b9344214e3eab5803689d1d8b5b@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1248 Wiki Page: | prime:Libraries/Proposals/MonadFail| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"fd6dd41c67f3bd23bbf074357219cfd251eb53d6/ghc" fd6dd41c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd6dd41c67f3bd23bbf074357219cfd251eb53d6" Implement `-Wnoncanonical-monadfail-instances` warning The MonadFail proposal implemented so far via #10751 only warns about missing `MonadFail` instances based on existence of failible pattern matches in `do`-blocks. However, based on the noncanonical Monad warnings implemented via #11150 we can provide a different mechanism for detecting missing `MonadFail` instances quite cheaply. That is, by checking for canonical `fail` definitions. In the case of `Monad`/`MonadFail`, we define the canonical implementation of `fail` to be such that the soft-deprecated method shall (iff overridden) be defined in terms of the non-deprecated method. Consequently, in case of `MonadFail`, the `Monad(fail)` method shall be defined as alias of the `MonadFail(fail)` method. This allows us at some distant point in the future to remove `fail` from the `Monad` class, while having GHC ignore/tolerate such literal canonical method definitions. Reviewed By: bgamari, RyanGlScott Differential Revision: https://phabricator.haskell.org/D1838 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 20:55:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 20:55:27 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.3bf037ad53d72509303865caf9b88442@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've been playing around with various ways that we could achieve this. As far as I can tell there are two options, * Encode type constructor kinds into `TyCon` and reconstruct applications from these at runtime. This would require that `TyCon` get a bit larger, and would need to include a `TypeRep`, which is unfortunate as this cost is paid by all users, regardless of whether they use `Typeable`. * Construct the kind representation at when we are asked to construct a `Typeable` dictionary. At the moment I'm leaning towards the second approach (and have a broken implementation in Phab:D1830). The trouble is that you need to be very careful when handling recursive kinding relationships. Consider, for instance, these examples: {{{#!hs (->) :: (->) * (* -> *) TYPE :: Levity -> TYPE 'Lifted }}} Here the types we are trying to derive kind representations for appear in their own kinds. This causes trouble in solving for these representations: Currently we construct `Typeable` evidence by decomposing type applications until we hit a tycon. One way to account for kind representations would be to require that when generating evidence for `Typeable (t :: k)` we also generate evidence for `Typeable k`. However, if we do this naively we end up sending the solver in a loop. Consider the case we are asked to solve for `Typeable (Int -> Bool)`. Evidence construction would roughly proceed as follows, {{{ want (Typeable (Int -> Bool :: *)) want (Typeable ((->) :: (* -> * -> *)) -- Normally this isn't a problem: -- since (->) is a TyCon, we could -- just stop here; but... -- now we need a kind representation want (Typeable (* -> * -> *)) want (Typeable ((->) * (* -> *))) -- again we decompose want (Typeable (->)) want (Typeable (* -> * -> *)) -- again solve for kind of (->) ... -- now we are in a loop... }}} Likewise, we can also get non-trivial cycles, {{{#!hs Levity :: TYPE 'Lifted TYPE :: Levity -> TYPE 'Lifted 'Lifted :: Levity }}} One way to address this issue would be to manually define these representations (just as we did before my recent solution to #11120), allowing us to tie the knot. It's possible, however, that I have fundamentally misunderstood something here. If so, please feel free to say so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 21:04:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 21:04:41 -0000 Subject: [GHC] #11485: Very unhelpful message resulting from kind mismatch In-Reply-To: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> References: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> Message-ID: <065.5d4dddb537d5f6e027807eda1ae520c2@haskell.org> #11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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 RyanGlScott): * cc: goldfire (added) Comment: goldfire, I believe the kind equalities patch caused this, so I'm CC'ing you (specifically, it's `msg5` that's causing this: http://git.haskell.org/ghc.git/blobdiff/6e56ac58a6905197412d58e32792a04a63b94d7e..6746549772c5cc0ac66c0fce562f297f4d4b80a2:/compiler/typecheck/TcErrors.hs). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 24 21:25:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jan 2016 21:25:42 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.76b684eb350b87bf480ee10232465e1d@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by thomie): Thanks, I can reproduce it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 02:53:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 02:53:08 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case Message-ID: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case --------------------------------------+---------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The body of `stg_ap_pp_fast` looks like {{{ arity = TO_W_(StgFunInfoExtra_arity(%GET_FUN_INFO(R1))); ASSERT(arity > 0); if (arity == 1) { Sp_adj(-2); W_[Sp+WDS(1)] = R3; W_[Sp+WDS(0)] = stg_ap_p_info; R1 = R1 + 1; jump_SAVE_CCCS(%GET_ENTRY(UNTAG(R1))); } if (arity == 2) { Sp_adj(0); R1 = R1 + 2; jump %GET_ENTRY(UNTAG(R1)) [R1,R2,R3]; } else { Sp_adj(-3); W_[Sp+WDS(2)] = R3; W_[Sp+WDS(1)] = R2; if (arity < 4) { R1 = R1 + arity; } BUILD_PAP(2,2,stg_ap_pp_info,FUN); } }}} where {{{ // Jump to target, saving CCCS and restoring it on return #if defined(PROFILING) #define jump_SAVE_CCCS(target) \ Sp(-1) = CCCS; \ Sp(-2) = stg_restore_cccs_info; \ Sp_adj(-2); \ jump (target) [R1] #else #define jump_SAVE_CCCS(target) jump (target) [R1] #endif }}} So in the arity=1 case the jump amounts to {{{ jump (%GET_ENTRY(UNTAG(R1))) [R1] }}} R1 is the function to apply, but we don't pass its argument, R2! Now, possibly by design, the calling convention of `stg_ap_pp_fast` is such that the first argument to apply is in R2, which is the same register that the function R1 will expect to find its argument in. So if nothing happens to disturb R2 (and possibly this is always the case with the NCG), then everything is fine. However, it's definitely not fine for the LLVM backend, which quite reasonably passes `undef` for the R2, R3, and R4 arguments when doing the jump. On arm/Android, LLVM decided to clobber `r8` (the physical register for R2) in the body of `stg_ap_pp_fast`. This caused a crash for the following program: {{{ main = print (read "3"::Int) }}} This appears to have been broken by commit f9265dd369b9e269349930012c25e670248f2a09 which changed the argument list for `jump_SAVE_CCCS` from `[*]` to `[R1]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 02:56:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 02:56:07 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.8f8838bc6eafbad2b4203ed51ef6520f@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Description changed by rwbarton: @@ -53,1 +53,2 @@ - `r8` (the physical register for R2) in the body of `stg_ap_pp_fast`. + `r8` (the physical register for R2) in the body of `stg_ap_ppp_fast` + (which has the same problems as `stg_ap_pp_fast`). New description: The body of `stg_ap_pp_fast` looks like {{{ arity = TO_W_(StgFunInfoExtra_arity(%GET_FUN_INFO(R1))); ASSERT(arity > 0); if (arity == 1) { Sp_adj(-2); W_[Sp+WDS(1)] = R3; W_[Sp+WDS(0)] = stg_ap_p_info; R1 = R1 + 1; jump_SAVE_CCCS(%GET_ENTRY(UNTAG(R1))); } if (arity == 2) { Sp_adj(0); R1 = R1 + 2; jump %GET_ENTRY(UNTAG(R1)) [R1,R2,R3]; } else { Sp_adj(-3); W_[Sp+WDS(2)] = R3; W_[Sp+WDS(1)] = R2; if (arity < 4) { R1 = R1 + arity; } BUILD_PAP(2,2,stg_ap_pp_info,FUN); } }}} where {{{ // Jump to target, saving CCCS and restoring it on return #if defined(PROFILING) #define jump_SAVE_CCCS(target) \ Sp(-1) = CCCS; \ Sp(-2) = stg_restore_cccs_info; \ Sp_adj(-2); \ jump (target) [R1] #else #define jump_SAVE_CCCS(target) jump (target) [R1] #endif }}} So in the arity=1 case the jump amounts to {{{ jump (%GET_ENTRY(UNTAG(R1))) [R1] }}} R1 is the function to apply, but we don't pass its argument, R2! Now, possibly by design, the calling convention of `stg_ap_pp_fast` is such that the first argument to apply is in R2, which is the same register that the function R1 will expect to find its argument in. So if nothing happens to disturb R2 (and possibly this is always the case with the NCG), then everything is fine. However, it's definitely not fine for the LLVM backend, which quite reasonably passes `undef` for the R2, R3, and R4 arguments when doing the jump. On arm/Android, LLVM decided to clobber `r8` (the physical register for R2) in the body of `stg_ap_ppp_fast` (which has the same problems as `stg_ap_pp_fast`). This caused a crash for the following program: {{{ main = print (read "3"::Int) }}} This appears to have been broken by commit f9265dd369b9e269349930012c25e670248f2a09 which changed the argument list for `jump_SAVE_CCCS` from `[*]` to `[R1]`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 03:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 03:01:16 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.b3ae43b1ecb254c378309f0dbd413e58@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Description changed by rwbarton: @@ -60,0 +60,1 @@ + when built with `-debug`. New description: The body of `stg_ap_pp_fast` looks like {{{ arity = TO_W_(StgFunInfoExtra_arity(%GET_FUN_INFO(R1))); ASSERT(arity > 0); if (arity == 1) { Sp_adj(-2); W_[Sp+WDS(1)] = R3; W_[Sp+WDS(0)] = stg_ap_p_info; R1 = R1 + 1; jump_SAVE_CCCS(%GET_ENTRY(UNTAG(R1))); } if (arity == 2) { Sp_adj(0); R1 = R1 + 2; jump %GET_ENTRY(UNTAG(R1)) [R1,R2,R3]; } else { Sp_adj(-3); W_[Sp+WDS(2)] = R3; W_[Sp+WDS(1)] = R2; if (arity < 4) { R1 = R1 + arity; } BUILD_PAP(2,2,stg_ap_pp_info,FUN); } }}} where {{{ // Jump to target, saving CCCS and restoring it on return #if defined(PROFILING) #define jump_SAVE_CCCS(target) \ Sp(-1) = CCCS; \ Sp(-2) = stg_restore_cccs_info; \ Sp_adj(-2); \ jump (target) [R1] #else #define jump_SAVE_CCCS(target) jump (target) [R1] #endif }}} So in the arity=1 case the jump amounts to {{{ jump (%GET_ENTRY(UNTAG(R1))) [R1] }}} R1 is the function to apply, but we don't pass its argument, R2! Now, possibly by design, the calling convention of `stg_ap_pp_fast` is such that the first argument to apply is in R2, which is the same register that the function R1 will expect to find its argument in. So if nothing happens to disturb R2 (and possibly this is always the case with the NCG), then everything is fine. However, it's definitely not fine for the LLVM backend, which quite reasonably passes `undef` for the R2, R3, and R4 arguments when doing the jump. On arm/Android, LLVM decided to clobber `r8` (the physical register for R2) in the body of `stg_ap_ppp_fast` (which has the same problems as `stg_ap_pp_fast`). This caused a crash for the following program: {{{ main = print (read "3"::Int) }}} when built with `-debug`. This appears to have been broken by commit f9265dd369b9e269349930012c25e670248f2a09 which changed the argument list for `jump_SAVE_CCCS` from `[*]` to `[R1]`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 04:08:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 04:08:40 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.159f657b5e663ba83af3607ed5b8524a@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 08:42:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 08:42:56 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.9f3795594b48ad6465ff0abb9b9230a6@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:28 RyanGlScott]: > Simon, I believe we will have precisely what you described with Phab:D1825. `-Wname-shadowing` controls unused `forall`-ed type variables, and `-Wtype-variables` controls unused type patterns separately. You can enable different combinations of them to achieve A, B, and C. OK good. Minor suggestions: * Personally I think `-Wunused-matches` is a bit surprising as a control for `forall`'d type variables. I suggest `-Wunused-foralls`. Having one more warning flag is low overhead. * The documentation for `-Wunused-matches` is out of date. * I really like the specification that: "if a type variable bound by an explicit, user-written forall is unused, we warn". Let's use it for `-Wunused-foralls`. And mention it in the section on explicit `forall` (9.14.1). * In the documentation for `-Wunused-type-variables` I think it is helpful to speak of "type patterns", and contrast with `-Wunused-foralls` (cross- ref in manual). * No one is pushing for extending `-Wunused-type-variables` to class instances. It's a little inconsistent but I think fair enough. Maybe in the documentation for `-Wunused-type-varaibles` mention this point. > The only remaining question is if we want a single flag that implies C (my previous name suggestion was `-pedantic`). This would be pretty easy to implement if we wanted it, since it would just enable a superset of the flags implied by `-Wall`. Separately [wiki:Design/Warnings] is debating sets of flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 08:45:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 08:45:44 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.b66bebff8646c69bc9dac8eeb0a9cffc@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be great if someone picked this up. There is helpful diagnosis above, but it does need someone to take a careful look and propose something concrete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 08:46:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 08:46:55 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.0c9bf768df204b86eaff45421b01f0f2@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): When trying to look at D1833, I get "You Shall Not Pass: Restricted Differential Revision" from Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 08:49:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 08:49:39 -0000 Subject: [GHC] #11485: Very unhelpful message resulting from kind mismatch In-Reply-To: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> References: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> Message-ID: <065.472bfcb114add0832d3f923e40b974ca@haskell.org> #11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType 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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 08:51:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 08:51:05 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.aede651a80dc67339584048c9e2dbcb3@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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 simonpj): * cc: simonmar (added) Comment: Simon O, Simon M, it'd b good to nail this. Looks bad to me. Well spotted Reid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 09:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 09:13:30 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.205c9b625dbe10689b1538014bc8c403@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: | PatternSynonyms 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: newcomer => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 09:16:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 09:16:21 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.507f9d48b299e419f3da1f4db11f2d43@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | 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 adamgundry): * keywords: DuplicateRecordFields => DuplicateRecordFields, ORF * owner: => adamgundry Comment: The `$sel`-prefixed things are the internal `Name`s of record fields in modules for which `DuplicateRecordFields` is enabled. I tried to catch all the places where they might show up in user-facing output, but it's not at all surprising that I've missed some. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 09:42:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 09:42:47 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.84cb0fd57f4416e565df5310d32dc9fb@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm lost on this thread. Can someone re-state what the ''specification'' is? And do so without reference to the preceding 24 comments. Just a free-standing description of the problem we are trying to solve. I can't begin to think about an implementation until I'm clear about specification. Also, can you do that in the light of the (recently-published) [http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell- dynamic/ A reflection on types]? It describes the story about type representation that I hope to get into HEAD once 8.0 is out of the way. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 09:47:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 09:47:29 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.924b08544a6ea56de4a2e440dc48c48c@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Changes (by simonpj): * cc: gmainland (added) Comment: Sounds bad to me. Geoff, can you comment as the author of the commit Reid identifies? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 10:31:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 10:31:10 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.e43020e08fa347b845e88179c5ccc73c@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): My goal was to augment the existing `Typeable` interface with a means of extracting the kind of the type represented by a given `TypeRep`. That is, {{{#!hs -- The current (non-type-indexed) TypeRep machinery data TypeRep type KindRep = TypeRep typeRep :: Typeable a => Proxy a -> TypeRep -- I wanted this... typeRepKind :: TypeRep -> KindRep }}} As far as I can tell, the semantics of `typeRepKind` should be clear so long as we are only talking about monomorphically kinded types. For instance, {{{#!hs kindRep :: Typeable a => Proxy a -> KindRep kindRep = typeRepKind . typeRep kindRep (Proxy :: Proxy Int) == * kindRep (Proxy :: Proxy Int#) == TYPE 'Unlifted kindRep (Proxy :: Proxy '[4]) == '[Nat] kindRep (Proxy :: Proxy (4 ':)) == '[Nat] -> '[Nat] kindRep (Proxy :: Proxy []) == * -> * kindRep (Proxy :: Proxy [Int]) == * kindRep (Proxy :: Proxy ((->) Int)) == * -> * kindRep (Proxy :: Proxy Eq) == * -> Constraint kindRep (Proxy :: Proxy (':)) insoluble kindRep (Proxy :: Proxy 'Just) insoluble }}} I have not thought much about this might fit in to the new type-indexed `TypeRep`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:07:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:07:56 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.79aa7dca2b45d5d9701e552ea881f418@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Perhaps something like this? {{{#!hs data Fingerprint = Fingerprint {- Int -} data TyCon a = TyCon Fingerprint String data TypeRep (a :: k) where TypeCon :: TyCon a -> TypeRep k -> TypeRep (a :: k) TypeApp :: forall k a (b :: k). TypeRep (a -> b) -> TypeRep a -> TypeRep (b :: k) class Typeable k => Typeable (a :: k) where typeRep :: Proxy a -> TypeRep a typeRepKind :: TypeRep (a :: k) -> TypeRep k typeRepKind (TypeCon _ k) = k typeRepName :: TypeRep a -> String typeRepName (TypeCon (TyCon _ n) _) = n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:10:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:10:02 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) (was: Type-indexed TypeReps, Static Pointers and Distributed Closures) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.81f479516d7b4641aa034091f000f3ec@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -1,4 +1,4 @@ - There is a mock-up of a new API for type indexed type representations, - basic Dynamic functionality, static pointers and distributed closures - (https://github.com/brprice/typeableT), based on - https://ghc.haskell.org/trac/ghc/wiki/TypeableT. + We have a plan to move to a '''type-indexed form of `TypeRep`. This + ticket serves to track progress. + + The key wiki page [wiki:Typeable]. @@ -7,1 +7,1 @@ - this ticket as a more permenant home that email. + this ticket as a more permanent home than email. @@ -9,2 +9,4 @@ - One particular point that would benefit from more eyes is the polymorphic - static pointers support. + There is a also a broader question, about using the new expressiveness of + `TypeRep` and `Typeable` to support static pointers. One particular point + that would benefit from more eyes is the polymorphic static pointers + support. But first things first! New description: We have a plan to move to a '''type-indexed form of `TypeRep`. This ticket serves to track progress. The key wiki page [wiki:Typeable]. We would like to invite comments and discussion from the community using this ticket as a more permanent home than email. There is a also a broader question, about using the new expressiveness of `TypeRep` and `Typeable` to support static pointers. One particular point that would benefit from more eyes is the polymorphic static pointers support. But first things first! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:10:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:10:25 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.5824a8eb7a795e23b6e3b278206f028a@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -1,1 +1,1 @@ - We have a plan to move to a '''type-indexed form of `TypeRep`. This + We have a plan to move to a '''type-indexed form of `TypeRep`'''. This @@ -4,1 +4,1 @@ - The key wiki page [wiki:Typeable]. + The key wiki page is: [wiki:Typeable]. New description: We have a plan to move to a '''type-indexed form of `TypeRep`'''. This ticket serves to track progress. The key wiki page is: [wiki:Typeable]. We would like to invite comments and discussion from the community using this ticket as a more permanent home than email. There is a also a broader question, about using the new expressiveness of `TypeRep` and `Typeable` to support static pointers. One particular point that would benefit from more eyes is the polymorphic static pointers support. But first things first! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:11:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:11:00 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.26ebe1e5549d9bfa881de2d0ae2cc490@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so the payload is that you want {{{ typeRepKind : forall (k::*). forall (a::k). TypeRep a -> TypeRep k }}} At least I think that's the right type. That's a nice short specification. I hope that it would not be too hard to implement. The whole project of moving from the existing to the new `TypeRep` needs someone to lead it; maybe that can be your weekend project! The key ticket is #11011, and wiki page [wiki:Typeable]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:15:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:15:53 -0000 Subject: [GHC] #11483: Ghci integration with readline In-Reply-To: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> References: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> Message-ID: <058.41de4002765125dfb59339e716c91181@haskell.org> #11483: Ghci integration with readline -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Geraldus Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: readline | complete Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10576 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I assume that GHCi completes identifiers, not language keywords. Thus I think that the current behavior is not a bug, but your ticket could be considered a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:20:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:20:32 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.875344daa7e43f91f1b18591bdcb93a6@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > The whole project of moving from the existing to the new TypeRep needs someone to lead it; maybe that can be your weekend project! Indeed I have been eyeing it. I thought exposing kind representations would be a good warm-up, although at various points over the weekend I've considered going all-in and going ahead with the new `TypeRep`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:21:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:21:38 -0000 Subject: [GHC] #11482: Turn -fdefer-typed-holes on by default In-Reply-To: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> References: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> Message-ID: <060.1c96a97fcaa15a6083c077ef427f8426@haskell.org> #11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): A different approach to the problem would be a TotalHaskell extension. The first and simple approach would be to warn about any use of `undefined` and `error`, and the second much more sophisticated approach would be to warn only about bottoms that can be reached plus a termination check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:22:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:22:07 -0000 Subject: [GHC] #11476: gcc leaves undeleted temporary files when invoked with a response file In-Reply-To: <047.e3b961b76b117f25353aec347110b896@haskell.org> References: <047.e3b961b76b117f25353aec347110b896@haskell.org> Message-ID: <062.473576478a31f838824728bc10e88b73@haskell.org> #11476: gcc leaves undeleted temporary files when invoked with a response file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by tuncer): || gcc bug || https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351 || || gcc patch || https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01487.html || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:31:13 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.7387203f318b7b71498d6f35c7476d18@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: #11449, #11451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"746764cce9a111a082a13bc3cd34b50e34fd2a31/ghc" 746764cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="746764cce9a111a082a13bc3cd34b50e34fd2a31" Refactor validity checking for type/data instances I found that there was some code duplication going on, so I've put more into the shared function checkValidFamPats. I did some refactoring in checkConsistentFamInst too, preparatory to #11450; the error messages change a little but no change in behaviour. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:31:13 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.3cfe27c098c86347b78c42579b63a8f7@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ff21795a0b9253e811a45626d5686e981ed07f82/ghc" ff21795a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ff21795a0b9253e811a45626d5686e981ed07f82" Special-case implicit params in superclass expansion This issue came up in Trac #11480, and is documented in Note [When superclasses help] in TcRnTypes. We were getting a spurious warning T11480.hs:1:1: warning: solveWanteds: too many iterations (limit = 4) The fix is easy. A bit of refactoring along the way. The original bug report in Trac #11480 appears to work fine in HEAD and the 8.0 branch but I added a regression test in this commit as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:31:13 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.6aebe6364d9941351a638374035a8969@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: #11330 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3c060f36f6eb4d359f252168e2f97b573d017080/ghc" 3c060f36/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3c060f36f6eb4d359f252168e2f97b573d017080" Fix exprIsHNF (Trac #11248) Blimey! CoreUtils.exprIsHNFlike had not one but two bugs. * is_hnf_like treated coercion args like type args (result: exprIsHNF might wrongly say True) * app_is_value treated type args like value args (result: exprIsHNF might wrongly say False) Bizarre. This goes back to at least 2012. It's amazing that it hasn't caused more trouble. It was discovered by a Lint error when compiling Trac #11248 with -O. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:31:13 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.1195816f08e5db55599b531b22c54d91@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"42c6263f23cf3f00035389637862944e0594bc7a/ghc" 42c6263f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42c6263f23cf3f00035389637862944e0594bc7a" Avoid recursive use of immSuperClasses In fixing Trac #11480 I had omitted to deal with FunDeps.oclose, which was making recursive use of immSuperClasses, and hence going into a loop in the recursive case. Solution: use transSuperClasses, which takes care not to. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:41:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:41:29 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.82c9e9a0a950b0d02c1b7331fcf6f32a@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's ''not'' implement `typeRepKind` in the existing `TypeRep` setup. First move to the new one! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:44:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:44:59 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.8fcac8a7c34363c74ead07e713fabc78@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11480, | polykinds/T11480a Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T11480, polykinds/T11480a Comment: OK I've fixed both the original report (with the commit in comment:9) and comment:2 (the commit in comment:8). Pls merge both. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:45:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:45:41 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.e1be1beb7cbc4094a6c4ca29ef99fad1@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: #11449, #11451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch in comment:19 does not resolve the ticket; it's just groundwork. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 11:46:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 11:46:13 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.579ba0f30945da88dc66a7077ac12a93@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: #11330 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Thanks for highlighting this. Fixed. Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 12:17:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 12:17:42 -0000 Subject: [GHC] #8325: Pattern guards in anonymous functions In-Reply-To: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> References: <046.8313544543d1ded0a9b092d4963db5c2@haskell.org> Message-ID: <061.0adc2ac21794c3709caa7f164cb33c48@haskell.org> #8325: Pattern guards in anonymous functions -------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7783, #10807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Wouldn't it be the `|` that introduces the layout? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 12:24:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 12:24:07 -0000 Subject: [GHC] #11306: Do not generate warning in `do` when result is of type `Void`. In-Reply-To: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> References: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> Message-ID: <062.ad8e0b91ef845c7e1859dc88f54f6c7d@haskell.org> #11306: Do not generate warning in `do` when result is of type `Void`. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 goldfire): * status: new => infoneeded Comment: Iavor, do you have an example illustrating your need here? I agree with comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 12:34:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 12:34:29 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.f746c3f66de28cf0b6dbf64ae393527f@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Working for me now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:03:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:03:43 -0000 Subject: [GHC] #10560: -f and -O options interact in non-obvious, order dependent ways In-Reply-To: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> References: <046.4b383b5f0fce35e0e7803ffe12bdc717@haskell.org> Message-ID: <061.41b6cfb1af26ee4c83c55be47298019c@haskell.org> #10560: -f and -O options interact in non-obvious, order dependent ways -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"128b678061120270d3d4fe3eccd1b7dc76a8de35/ghc" 128b678/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="128b678061120270d3d4fe3eccd1b7dc76a8de35" user-guide: Note order-dependence of flags This supplements the description previously added in 6400c7687223c5b2141176aa92f7ff987f61aba6. See #10560 for details. Test Plan: read it Reviewers: austin Subscribers: thomie, hvr Differential Revision: https://phabricator.haskell.org/D1831 GHC Trac Issues: #10560 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:03:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:03:43 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.c843c842696604f88255e4667e2d1ef8@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1248 Wiki Page: | prime:Libraries/Proposals/MonadFail| -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"132c20894d102558cc8f3aee5bc289425d0ddb24/ghc" 132c2089/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="132c20894d102558cc8f3aee5bc289425d0ddb24" Rename -Wmissing-monadfail-instance to plural-form This warning flag was recently introduced as part of #10751. However, it was missed during code-review that almost all existing warning flags use a plural-form, so for consistency this commit renames that warning flag to `-Wmissing-monadfail-instances`. Test Plan: local validate (still running) Reviewers: quchen, goldfire, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1842 GHC Trac Issues: #10751 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:05:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:05:03 -0000 Subject: [GHC] #11488: -dynamic-too is entirely undocumented Message-ID: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> #11488: -dynamic-too is entirely undocumented -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.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: -------------------------------------+------------------------------------- It seems like there are precisely zero mentions of the `-dynamic-too` flag in our user documentation. This may not be a flag that users will use often but it still needs documentation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:38:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:38:11 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.beafbb8e5ba98c0f643589dd0f87d525@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wholeheartedly agree with your points, although if we introduce a `-Wunused-foralls` flag, it will probably be confusing to also have `-Wunused-type-variables`, since `forall`-ed variables ''are'' type variables, after all. I think it might be better to rename `-Wunused-type- variables` to `-Wunused-type-patterns` in light of this (especially since you want to emphasize the distinction from `-Wunused-foralls`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:58:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:58:05 -0000 Subject: [GHC] #11478: ghc -e shouldn't print "Loaded GHCi configuration" message In-Reply-To: <047.ab61d3400307177855148860dc3d1387@haskell.org> References: <047.ab61d3400307177855148860dc3d1387@haskell.org> Message-ID: <062.58d947b0744a7c117a11618a9b252595@haskell.org> #11478: ghc -e shouldn't print "Loaded GHCi configuration" message -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 70f01d0ec4953eff985c856f5c9c3179e96fa8eb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:59:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:59:04 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.fbf2952d0294e45132dae97c2d25e476@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by HairyDude): * cc: HairyDude (added) Comment: Same on Windows 10, GHC 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:59:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:59:45 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.2aac4bb8277ee288036926458aad6788@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 4b4d4c34cb10ba34fa25e90bdd3b381440f9c43d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 15:59:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 15:59:58 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.cc0dcc8b67716972958c7a0d87c8b442@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: fixed | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:00:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:00:31 -0000 Subject: [GHC] #11056: Need to generate Typable info for promoted data constructors In-Reply-To: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> References: <046.10d6ee6a6f34d362ec160d92f2757040@haskell.org> Message-ID: <061.a0c4d6984a0bdfb49a0a3fa5efb6781c@haskell.org> #11056: Need to generate Typable info for promoted data constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 46d784021737912706f21fcee40e3750dc2dcd9c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:01:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:01:12 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.e91b4acab24951c307f5082da9033b61@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by nomeata): I have made initial, still hackish, progress. After a few iterations I can now run all of nofib with my counting indirections and it does not segfault any more (phew). Here is a report from `integrate`, note the new columns `#Alloc`, `Single` and `Multpile`. {{{ Entries Alloc Alloc'd #Alloc Single Multiple Non- void Arguments STG Name -------------------------------------------------------------------------------- 50000 800000 0 0 0 0 1 D main at main:Main.main6{v r7sX} 0 0 8000000 500000 0 0 0 sat_s7u6{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7u3{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7tZ{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7tU{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7tP{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7tK{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7tF{v} (main at main:Main) (thk) in r7sQ 0 0 8000000 500000 0 0 0 sat_s7tA{v} (main at main:Main) (thk) in r7sQ 4050000 0 7200000 450000 0 450000 1 D sat_s7uz{v} (main at main:Main) in s7uB 0 0 8000000 500000 0 0 0 sat_s7tu{v} (main at main:Main) (thk) in r7sQ 500000 72000000 0 0 0 0 3 dd> main at main:Main.$wintegrate1D{v r7sQ} 450000 32400000 800000 50000 0 50000 1 D sat_s7uB{v} (main at main:Main) in r7t3 50000 800000 0 0 0 0 1 D main at main:Main.main10{v r7t2} 50000 3600000 0 0 0 0 2 DD main at main:Main.main11{v r7t3} 50000 0 0 0 0 0 4 LLid main at main:Main.$wgo{v r7t4} 2 0 24 1 1 0 0 sat_s7vH{v} (main at main:Main) (thk) in r7sR 1 64 0 0 0 0 0 main at main:Main.main1{v r7sR} 1 0 0 0 0 0 0 main at main:Main.main15{v r7t9} 1 0 0 0 0 0 0 main at main::Main.main{v 01D} }}} It is still buggy (or not fully understood), e.g.: * I thought I only enabled it for thunks, but it also seems to be present for two functions, and only there count multiple entries... Weird. * Also, these 500000-times allocated thunks are not really unused, are they?. * Two total entries for a thunk (`sat_s7vH`) that has been allocated once and called once? Maybe there was a heap check inbetween? But still: You can tell that `sat_s7uB` has been allocated 50000 and each instance is called 9 times ? this matches the 9-element-list in the code. The implementation uses a new closure type that carries a pointer to a ticky counter struct, and its own little counter: {{{ typedef struct { StgHeader header; StgClosure *indirectee; const void *ent_counter; // A StgEntCounter StgWord entries; } StgIndCounting; }}} Upon entry, this increments the private counter, and if it does so the first time, increases `Single`, and on the second time decreases `Single` and increases `Multiple`. Otherwise, it passes `R1` onto the indirectee, preserving the tag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:02:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:02:54 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.92c7f8e5b44ae29f2c298d36168f0ed4@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: fixed | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11480, | polykinds/T11480a Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Cherry-picked to `ghc-8.0` as 6217147e0895e98b08e597660ea941a544943a4d and e37b571baabf18621eb3b471fddc015a021ecf46. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:04:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:04:07 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.179890fb386ba7e704cdee9081f2d425@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: #11330 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 1e6bdbc83fb795015d48001dcb8c305ab690294c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:04:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:04:34 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.32d3173e990f598d4ac07085a99967a7@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1248 Wiki Page: | prime:Libraries/Proposals/MonadFail| -------------------------------------+------------------------------------- Comment (by bgamari): Renaming merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:31:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:31:51 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.4e9fcbc3e2b807e724ac3b919890f327@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:36:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:36:28 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.7e15f9a9f60873c736cd205ffe181442@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Good work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 16:55:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 16:55:44 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.2788e08a862b31c3a58e193a35127e10@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: Right. The "simplifier ticks exhausted" error is expected; see Section 7 of [http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell- dynamic/ the paper]. But the Lint error is an outright bug. I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:08:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:08:48 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.5fd552bb9233476e8ba2756365f09e79@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Adding the following seems to fix the error: {{{#!hs import GHC.IO.Encoding main = do ... setLocaleEncoding utf8 .... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:10:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:10:37 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.ed98cc7a3d3624fa5c3f5e9c09d4044c@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 HairyDude]: > Unfortunately this fix isn't very portable. Also, I ''think'' this "fix" depends on if you're running from MSYS/Cygwin (where it's a sufficient fix) or `cmd.exe`/PowerShell (where it fixes the warning, put doesn't output the character correctly). Can you confirm what shell you're using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:12:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:12:04 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.f44d1b20bd34595d132203f00a3b398c@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've updated Phab:D1825 to incorporate Simon's suggestions. Feedback is appreciated, since much of the changes are documentation-related (and you might want me to be more explicit about something you care about). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:36:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:36:01 -0000 Subject: [GHC] #11449: Treat '_' consistently in type declarations In-Reply-To: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> References: <046.90af97e65bc1bb376f4ebcab56fd123d@haskell.org> Message-ID: <061.352e74d9adb0452b73c702939a52a7cf@haskell.org> #11449: Treat '_' consistently in type declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:37:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:37:31 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.c6d56bec7bfced49c447ebd2092e8cbf@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Changes (by WrenThornton): * cc: wren@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:46:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:46:40 -0000 Subject: [GHC] #9149: Description of openFileBlocking is wrong In-Reply-To: <044.5c835f25372cd920667deec884e080e9@haskell.org> References: <044.5c835f25372cd920667deec884e080e9@haskell.org> Message-ID: <059.f7e6873fb65d379856a95207cac9b76f@haskell.org> #9149: Description of openFileBlocking is wrong -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.8.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as ede37fd29e6dc1b4a832172b29eee3baff165306. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 17:50:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 17:50:36 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.39e5aee43707ff3c9fb975816b0df708@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Changes (by bgamari): * priority: high => highest Comment: Seems like this should really be highest priority given this has the potential to cause crashes and is working by mere chance at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 20:19:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 20:19:06 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.b4a002c8052b479c3793978b76567213@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: infoneeded => new Comment: Reid has confirmed that this builds on Phab:D1704 with a cross-compiler for ARMv5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 20:19:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 20:19:18 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.72e6d40a603aa690a05dd8e23a929ce0@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 20:43:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 20:43:47 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.a4e372cd1d255b3f3c1022b7e1b4f409@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 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): Phab:D1830 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0f63b39783055b2c0c1a8db8c22749afa6d7329/ghc" f0f63b39/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0f63b39783055b2c0c1a8db8c22749afa6d7329" Implement -Wunrecognised-warning-flag This allows the user to avoid warnings for warning flags that GHC doesn't recognise. See #11429 for details.. Test Plan: Validate with T11429[abc] tests Reviewers: austin, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1830 GHC Trac Issues: #11429 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 20:43:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 20:43:48 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.054922505c405ce98d722641a728683c@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"9fe7d20e2e5c60325ce04f476bc89fae06e43208/ghc" 9fe7d20e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9fe7d20e2e5c60325ce04f476bc89fae06e43208" Ensure that we don't produce code for pre-ARMv7 without barriers We are unable to produce load/store barriers for pre-ARMv7 targets. Phab:D894 added dummy cases to SMP.h for these barriers to prevent the build from failing under the assumption that there are no SMP-capable devices of this vintage. However, #10433 points out that it is more correct to simply set NOSMP for such targets. Tested By: rwbarton Test Plan: Validate Reviewers: erikd, rwbarton, austin Reviewed By: rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1704 GHC Trac Issues: #10433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:26:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:26:00 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.f167f32e6151476823cdc74c6b0bad29@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by mkarcher): * Attachment "0001-Extend-gcc-on-m68k-to-allow-calling-incorrectly- decl.patch" added. Patch for gcc to support the non-standard construct used by ghc on m68k. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:42:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:42:43 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.4ba781e54306a95794320f7724e6b9e9@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | 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): Phab:D1830 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `master` and `ghc-8.0` (as bbd935606422ca884a680afa806164d851fd5060). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:43:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:43:04 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.eaba5528c4189e37c581fb0fdb1082ec@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 761d423ec2723137c67942718b4d6d793716acff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:44:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:44:19 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.3a7e51514916a8bf8efe85f7d1966890@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 57bce48fccc3e8034767dff0d308f88ecbb907ec. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:45:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:45:05 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.86db55d9194c5376c1236b2431cdcfd9@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 26a9f13ca4f602749f0f00388a145badbf7c27dd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:45:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:45:34 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.27ef43190ed4cbde9027aff3c2e31848@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => * status: closed => new * resolution: fixed => Comment: Unfortunately this fix wasn't quite right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 21:46:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 21:46:40 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.481ba7f56ce146bafc0f6744c8b38415@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822, Wiki Page: | Phab:D1844 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: Phab:D1822 => Phab:D1822, Phab:D1844 Comment: See Phab:D1844 for another attempt at a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:02:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:02:16 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable Message-ID: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce: {{{ $ echo 'main = return ()' > Test.hs $ touch Test.prof $ chmod -w Test.prof $ ghc -prof Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test +RTS -hr{} -hc Can't open profiling report file Test.prof Segmentation fault (core dumped) }}} The warning is ok (maybe it should be an error?), but it shouldn't segfault. Running `./Test +RTS -hr` works fine. http://downloads.haskell.org/~ghc/master/users-guide/profiling.html#rts- options-for-heap-profiling: * `-hc`: Breaks down the graph by the cost-centre stack which produced the data. * `-hr?cc?`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top. Bug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002): {{{ - you can now restrict a heap profile to certain retainer sets, but still display by cost centre (or type, or closure or whatever). }}} Because it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001): {{{ // The following line was added by Sung; retainer/LDV profiling may need // two output files, i.e., .prof/hp. if (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER) RtsFlags.ProfFlags.doHeapProfile = 0; }}} Another relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6: {{{ Author: simonmar Date: Wed Nov 28 15:42:26 2001 +0000 [project @ 2001-11-28 15:42:26 by simonmar] Don't need the .prof file when LDV-profiling. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:05:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:05:05 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.0e21910a7e50d878e12612a1e43be276@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1795 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1795 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:05:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:05:41 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup In-Reply-To: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> References: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> Message-ID: <057.5a888c7ed2a28f33e6412dcb6d234d20@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: pattern | checker, 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 bgamari): George, does Phab:D1795 address this as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:13:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:13:23 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.2b2e860a207a370355285bb21a6c28a1@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8299 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: => ? Comment: My very old patches are also here: https://github.com/rwbarton/ghc/tree/rwbarton-x32 I'm putting this on hold indefinitely though because recent Debian kernels no longer support x32 out of the box (you need a kernel command-line parameter to enable x32 support). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:14:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:14:04 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.c7311c3752168fda59b50ef041aa6a8d@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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): I suspect the issue here is the `pprSectionHeader` removed from `pprBasicBlock`. {{{#!patch @@ -113,7 +109,6 @@ pprBasicBlock info_env (BasicBlock blockid instrs) maybe_infotable = case mapLookup blockid info_env of Nothing -> empty Just (Statics info_lbl info) -> - pprSectionHeader Text $$ infoTableLoc $$ vcat (map pprData info) $$ pprLabel info_lbl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:14:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:14:12 -0000 Subject: [GHC] #8287: exploring calling convention changes and related engineering for 7.10 In-Reply-To: <045.594cdade97652c9633f43b7996da7568@haskell.org> References: <045.594cdade97652c9633f43b7996da7568@haskell.org> Message-ID: <060.6cb67449e714e90689041d694e840bae@haskell.org> #8287: exploring calling convention changes and related engineering for 7.10 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8299 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: ? => Comment: Er, this ticket wasn't specifically about x32 I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:20:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:20:45 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.e3698eb60ec443432747575a4ca3bce7@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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:D1846 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1846 Comment: Possibly fixed in Phab:D1846. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:49:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:49:08 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.6d513aa01c9b70de13d6daa9f93c0213@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by rwbarton): The commit in question does produce the correct argument list for the arity=2 case. So this is probably just a matter of going through all the other cases and making sure the argument lists are right. genapply is a bit large though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:53:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:53:13 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.96555b9b81dd5c2503e1046c543b540d@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 22:59:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 22:59:31 -0000 Subject: [GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling In-Reply-To: <045.6104ef63780cb1088603ac8080468c98@haskell.org> References: <045.6104ef63780cb1088603ac8080468c98@haskell.org> Message-ID: <060.1a74d167d93f51ddd6f5cb28a68cb2c3@haskell.org> #11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11470 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): In current cross-compiling builds, the stage1 compiler is a cross-compiler and the stage2 compiler is a native compiler for the target. I think you're talking about a scenario in which the stage1 compiler is a native compiler for the build system and the stage2 compiler is a cross-compiler. Otherwise, ghc-stage2 couldn't possibly link against the stage1 ghc library since they are built for different platforms. Is that right? If so, don't you have to also have to build all the libraries and the RTS twice. Once to be linked into the stage2 compiler which runs on the build system, and again to be linked into the executables that run on the target that are the output of the stage2 compiler. Similarly you have to detect the vagaries of both the host gcc, in order to build ghc-stage2, and the cross-compiling gcc, in order for ghc-stage2 to know how to build its output. Basically it seems like you have to do most of the work of #11470 anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 25 23:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jan 2016 23:10:09 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.b2e53efb9f9950b0c25e579a39392bbc@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by gmainland): My recollection is that we were saving too many registers and therefore taking a notable performance hit on LLVM. Now we are apparently saving too few, but only when saving the current cost centre stack :) If nobody else gets to it, I will put a patch on Phab within a week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 00:10:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 00:10:02 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable In-Reply-To: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> References: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> Message-ID: <060.cea839a0aca89c720a370802b9df2685@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.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 thomie): * owner: => thomie * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 00:14:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 00:14:08 -0000 Subject: [GHC] #11490: check architecture before attempting to load object files Message-ID: <047.ad616eb4613023971ded612b6102d5eb@haskell.org> #11490: check architecture before attempting to load object files -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 8.0.1-rc1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a user somehow manages to trick ghci into loading a `.o` file for the wrong architecture (e.g. arm vs x86), the runtime linker doesn't notice and tries to load it anyway. That is likely to result in a confusing error or crash. `ocVerifyImage_ELF` does already check the "ELF class", which amounts to 32-bit vs 64-bit. It should also check the architecture and, I think, endianness to make sure they are compatible with the running process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 01:56:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 01:56:02 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable In-Reply-To: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> References: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> Message-ID: <060.156bd034db36183dc1b93dc55fed0b93@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.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:D1849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1849 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 01:58:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 01:58:34 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable In-Reply-To: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> References: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> Message-ID: <060.79bc537d97631ecbc841f74f163c91be@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7149 | Differential Rev(s): Phab:D1849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #7149 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 02:01:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 02:01:39 -0000 Subject: [GHC] #7149: Heap profiling restricted with retainers (+RTS -hrfoo -hc) segfaults In-Reply-To: <043.fad91b326e57f8b55e28cc1840456d53@haskell.org> References: <043.fad91b326e57f8b55e28cc1840456d53@haskell.org> Message-ID: <058.92601d3fe8e44ce75bab3b66613c83ca@haskell.org> #7149: Heap profiling restricted with retainers (+RTS -hrfoo -hc) segfaults ----------------------------------+-------------------------------------- Reporter: akio | Owner: pcapriotti Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Profiling | Version: 7.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11489 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by thomie): * related: => #11489 Comment: This didn't fix the problem completely, or at least there was another bug in the same function 10 lines down, see #11489. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 02:02:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 02:02:28 -0000 Subject: [GHC] #11490: check architecture before attempting to load object files In-Reply-To: <047.ad616eb4613023971ded612b6102d5eb@haskell.org> References: <047.ad616eb4613023971ded612b6102d5eb@haskell.org> Message-ID: <062.7126a0520abba497b70e8b1917944ee7@haskell.org> #11490: check architecture before attempting to load object files -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.0.1-rc1 (Linker) | 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: | -------------------------------------+------------------------------------- Comment (by ezyang): Related: #7790 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 04:04:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 04:04:10 -0000 Subject: [GHC] #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan Message-ID: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan ----------------------------------------+--------------------------------- Reporter: hienqnguyen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: ----------------------------------------+--------------------------------- {{{ /Users/tdoan$ stack upgrade Fetched package index. Populated index cache. stack-1.0.2: download Warning: /private/var/folders/wl/8jbs0c_w8xj_5z0059bpz1v80000gn/T/stack- upgrade8446/stack-1.0.2/stack.yaml: Unrecognized field in ImageOptsMonoid: containers Cabal-1.22.6.0: copying precompiled package SHA-1.6.4.2: copying precompiled package ansi-terminal-0.6.2.3: copying precompiled package auto-update-0.1.3: copying precompiled package base-orphans-0.4.5: copying precompiled package base16-bytestring-0.1.1.6: copying precompiled package ansi-wl-pprint-0.6.7.3: download ansi-wl-pprint-0.6.7.3: configure base64-bytestring-1.0.0.1: copying precompiled package byteable-0.1.1: copying precompiled package bytestring-builder-0.10.6.0.0: copying precompiled package cereal-0.4.1.1: copying precompiled package cryptohash-0.11.6: copying precompiled package data-default-class-0.0.1: copying precompiled package ansi-wl-pprint-0.6.7.3: build dlist-0.7.1.2: copying precompiled package extra-1.4.2: download extra-1.4.2: configure extra-1.4.2: build ansi-wl-pprint-0.6.7.3: copy/register file-embed-0.0.9: download file-embed-0.0.9: configure file-embed-0.0.9: build file-embed-0.0.9: copy/register extra-1.4.2: copy/register filelock-0.1.0.1: download filelock-0.1.0.1: configure generics-sop-0.2.0.0: download filelock-0.1.0.1: build generics-sop-0.2.0.0: configure generics-sop-0.2.0.0: build filelock-0.1.0.1: copy/register gitrev-1.2.0: download gitrev-1.2.0: configure gitrev-1.2.0: build gitrev-1.2.0: copy/register hourglass-0.2.9: copying precompiled package ieee754-0.7.6: download ieee754-0.7.6: configure ieee754-0.7.6: build ieee754-0.7.6: copy/register Progress: 21/136 -- While building package generics-sop-0.2.0.0 using: /Users/tdoan/.stack/setup-exe-cache/x86_64-osx/setup-Simple- Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /private/var/folders/wl/8jbs0c_w8xj_5z0059bpz1v80000gn/T/stack- upgrade8446/stack-1.0.2/.stack-work/logs/generics-sop-0.2.0.0.log Configuring generics-sop-0.2.0.0... Building generics-sop-0.2.0.0... Preprocessing library generics-sop-0.2.0.0... [ 1 of 13] Compiling Generics.SOP.Sing ( src/Generics/SOP/Sing.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Sing.o ) [ 2 of 13] Compiling Generics.SOP.Constraint ( src/Generics/SOP/Constraint.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Constraint.o ) [ 3 of 13] Compiling Generics.SOP.BasicFunctors ( src/Generics/SOP/BasicFunctors.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/BasicFunctors.o ) [ 4 of 13] Compiling Generics.SOP.Classes ( src/Generics/SOP/Classes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Classes.o ) [ 5 of 13] Compiling Generics.SOP.NP ( src/Generics/SOP/NP.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/NP.o ) [ 6 of 13] Compiling Generics.SOP.Metadata ( src/Generics/SOP/Metadata.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Metadata.o ) [ 7 of 13] Compiling Generics.SOP.Dict ( src/Generics/SOP/Dict.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Dict.o ) [ 8 of 13] Compiling Generics.SOP.NS ( src/Generics/SOP/NS.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/NS.o ) [ 9 of 13] Compiling Generics.SOP.GGP ( src/Generics/SOP/GGP.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/GGP.o ) [10 of 13] Compiling Generics.SOP.Universe ( src/Generics/SOP/Universe.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Universe.o ) [11 of 13] Compiling Generics.SOP.TH ( src/Generics/SOP/TH.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/TH.o ) [12 of 13] Compiling Generics.SOP.Instances ( src/Generics/SOP/Instances.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Generics/SOP/Instances.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/wl/8jbs0c_w8xj_5z0059bpz1v80000gn/T/ghc8794_0/libghc_70.dylib, 5): Library not loaded: /usr/local/opt/ghc/lib/ghc-7.10.3/templ_GJPvtLC64aA4c1Jl10o2qt /libHStemplate-haskell-2.10.0.0-GJPvtLC64aA4c1Jl10o2qt-ghc7.10.3.dylib Referenced from: /var/folders/wl/8jbs0c_w8xj_5z0059bpz1v80000gn/T/ghc8794_0/libghc_70.dylib Reason: image not found Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /Users/tdoan$ stack --version Version 1.0.0 x86_64 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 04:12:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 04:12:30 -0000 Subject: [GHC] #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan In-Reply-To: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> References: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> Message-ID: <065.29c818061cb5544158356687b4c69114@haskell.org> #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan ---------------------------------+---------------------------------------- Reporter: hienqnguyen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 hienqnguyen): I tried to attach the file mentioned in the output above but it didn't seem to exist: {{{ /Users/tdoan$ ls /private/var/folders/wl/8jbs0c_w8xj_5z0059bpz1v80000gn/T /stack-upgrade8446/stack-1.0.2/.stack-work/logs/generics-sop-0.2.0.0.log ls: /private/var/folders/wl/8jbs0c_w8xj_5z0059bpz1v80000gn/T/stack- upgrade8446/stack-1.0.2/.stack-work/logs/generics-sop-0.2.0.0.log: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 04:13:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 04:13:19 -0000 Subject: [GHC] #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan In-Reply-To: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> References: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> Message-ID: <065.819e8ea836b19a94fd1578187917bde3@haskell.org> #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan ---------------------------------+---------------------------------------- Reporter: hienqnguyen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 rwbarton): Does `/usr/local/opt/ghc/lib/ghc-7.10.3/templ_GJPvtLC64aA4c1Jl10o2qt /libHStemplate-haskell-2.10.0.0-GJPvtLC64aA4c1Jl10o2qt-ghc7.10.3.dylib` exist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 07:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 07:18:59 -0000 Subject: [GHC] #11492: http://jackedmuscleextremeadvice.com/crevalor/ Message-ID: <047.a7165b40ccca8c055d1b8ad87f17cf1b@haskell.org> #11492: http://jackedmuscleextremeadvice.com/crevalor/ -------------------------------------+------------------------------------- Reporter: yanwitti | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 biggest error most people make gone it comes to how to construct thin muscles terse is to think that the number of repetitions they pro will back taking place its not real. [http://jackedmuscleextremeadvice.com/crevalor/ Crevalor] Heavier weights and functional out at a compound severity is how to construct thin muscles rapid. Working harder for a shorter period of era is the way to achieve the goals you indulgent. http://jackedmuscleextremeadvice.com/crevalor/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 08:21:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 08:21:34 -0000 Subject: [GHC] #11492: http://jackedmuscleextremeadvice.com/crevalor/ In-Reply-To: <047.a7165b40ccca8c055d1b8ad87f17cf1b@haskell.org> References: <047.a7165b40ccca8c055d1b8ad87f17cf1b@haskell.org> Message-ID: <062.79737944413703eee4bf1911441574e9@haskell.org> #11492: http://jackedmuscleextremeadvice.com/crevalor/ -------------------------------------+------------------------------------- Reporter: yanwitti | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari): * status: new => closed * resolution: => invalid Comment: I'm afraid I can't reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:12:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:12:18 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.3c90033c80ad26d7fb13b945d096a097@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by simonmar): Good catch! It looks wrong to me. You probably need to pass the list of argument registers to `jump_SAVE_CCS` and attach them to the final jump. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:30:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:30:37 -0000 Subject: [GHC] #11493: Merge compact normal forms Message-ID: <046.817f1145363bc4a821bde6cbb76b8fef@haskell.org> #11493: Merge compact normal forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 7.10.3 libraries/compact | 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: -------------------------------------+------------------------------------- Merge Yang and Campagna's [[Compact Normal Forms work|http://ezyang.com/compact.html]]. There are several pieces to this, * Types and construction logic for compact regions (see Phab:D1264) * Serialization and fixup logic (currently also in Phab:D1264) * Striped allocator for heap sharing between processes (allocator in Phab:D1434, CNF support in Phab:D1435). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:38:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:38:25 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.5cf8d017bca56f8c01bf35c0382886f1@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: 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): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:40:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:40:22 -0000 Subject: [GHC] Batch modify: #9630, #5642, #11068 Message-ID: <20160126104023.070D33A2FF@ghc.haskell.org> Batch modification to #9630, #5642, #11068 by thomie: keywords to Generics -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:48:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:48:36 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.44664c237aaa04b2ed7db55bbfddaa1a@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1c6d70c2121fd1126fcc2458bdbcc856e19598c2/ghc" 1c6d70c2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c6d70c2121fd1126fcc2458bdbcc856e19598c2" Kill off zipTopTCvSubst in favour of zipOpenTCvSubst As Bartosz has discovered, the invariants for substitutions were wrong, and in particular the "mkTop...Subst" and "zipTop..Subst" functions were building substitutions that didn't obey even the old invariants. This patch kills of the bogus zipTopTCvSubst in favour of the more robust zipOpenTCvSubst. I tripped over this because my upcoming patch (concerning SetLevels, Trac #11330) triggered an ASSERT failure in the substitution well-formedness assertion in TyCoRep. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:48:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:48:36 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.56e2ccccb117bcffa3dfa48170058708@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"016a0bd1ba129134dfa612db0d96e01644fa7b9f/ghc" 016a0bd1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="016a0bd1ba129134dfa612db0d96e01644fa7b9f" Fix two cloning-related bugs Crikey! Not just one but two bugs in type variable cloning, both dating from the days before PolyKinds. Both were shown up by Trac #11330. 1. In SetLevels, when floating a case expression we must clone its binders, *and* do so in a telescope-aware way, because the constructor may bind a kind variable that appears in the kind of a type variable. Instead of doing this (wrongly) by steam, call CoreSubst.cloneBndrs. I added Notes and did other refactoring at the same time. 2. It turned out that CoreSubst.cloneBndrs calls TyCoRep.cloneTyVarBndr, and that too was bogus! It didn't substitute in the kind of the TyVar being cloned. There was even a comment to say "variables can't appear in kinds". Thta hasn't been true for a long time now. Easily fixed. Interestingly, I then found that test dependent/should_compile/KindEqualities was emitting a new inexhaustive-pattern-match warning. Sure enough it was valid! So the lack of cloning in cloneTyVarBndr really was causing an observable bug; just one that we had not observed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 10:51:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 10:51:17 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.5372ea1a8b224cc9e2ddfbc154e3583f@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonmar): I propose: * Do not dynamically-link GHC on Windows * Do not build a dynamic version of the GHC package * Continue to build dynamic versions of everything else * Use Remote GHCi (`-fexternal-interpreter`) to get dynamic linking in GHCi * Close this ticket :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 11:00:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 11:00:45 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.2 In-Reply-To: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> References: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> Message-ID: <061.cf82cd0ac8bae88d2f86c555403d199d@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 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): * version: 7.10.3 => 8.0.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 11:14:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 11:14:02 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.0cf45442bc6a96a13b0bc330163a76ed@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge Comment: Seems like this is something we probably want in 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 11:14:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 11:14:51 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.a926547cfa20e125fb54094490f76d76@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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:D1847 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D1846 => Phab:D1847 Comment: More thorough fix in Phab:D1847. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 11:42:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 11:42:45 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.4778ad3dee8b0e112cf1853ad26d8b39@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"f1885dfd7ee84fae478e2e8398d2eff14ee36b2c/ghc" f1885df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f1885dfd7ee84fae478e2e8398d2eff14ee36b2c" Update process submodule to 1.4.2.0 release Most notably, this pulls in a feature needed for #11100 (remote ghci) windows-support }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 11:50:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 11:50:32 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.4348337f73ba22d981b52ef52e174ef7@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: fixed | loopification, code generation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): [https://perf.haskell.org/ghc/#revision/4d51bfc8975f9c6c3ab6d293c48f98da85210d5f GHC Speed] results are in: {{{ nofib/time/fannkuch-redux 3.153 - 11.45% 2.792 seconds nofib/time/n-body 0.886 - 3.61% 0.854 seconds }}} Nice! Also interesting is the stabilization of the n-body performance in this [https://perf.haskell.org/ghc/#graph/nofib/time/n-body;hl=4d51bfc8975f9c6c3ab6d293c48f98da85210d5f graph]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 11:52:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 11:52:19 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.d51b3e45284b7b6a06693f38f529c99a@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, do merge. The only test case I know of is `dynamic-paper` in way `hpc`. I might be able to cook up a simpler test case, but I'm out of time and the fix really has fixed it. So I'll leave it without adding a better regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 12:33:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 12:33:48 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.d6d53654e8902431b5e4f454120b3610@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you sure? exceptionsrun001 seems OK to me. It turns out that the other three all relied on imprecise exceptions being precise. Eg conc012 has {{{ forkIO $ Control.Exception.catch (x `seq` putMVar result Finished) $ }}} If you want to be sure that `x` will only be evaluated under the `catch` you must use `evaluate` thus: {{{ forkIO $ Control.Exception.catch (evaluate x >> putMVar result Finished) $ }}} Similarly conc014 had {{{ error "wibble" `Control.Exception.catch` ... }}} But the `error "wibble"` is a pure bottom value and we make no guarantees about when it is evaluated. It should be more like {{{ throwIO (ErrorCall "wibble") `Control.Exception.catch` .... }}} which raises the exception in the IO monad (i.e. precisely). Same with `T3279`, which had {{{ error "foo" `catch` \(SomeException e) -> do }}} Again that `error "foo"` should be `throwIO (ErrorCall "foo")`. Incidentally, is there a function for `throwIO . ErrorCall`? I'll make a patch for these three tests. Then I claim we are done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 12:36:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 12:36:05 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.a481aec38dd0c4d45892153a023843f5@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3798b2aad8f62cb18e6147b54c57a9a4ad6c23f4/ghc" 3798b2a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3798b2aad8f62cb18e6147b54c57a9a4ad6c23f4" Fix three broken tests involving exceptions See comment:16 in Trac #10712. The tests were wrong, not GHC! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 12:38:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 12:38:10 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.94079042eb533af757cfc3b87d4d3dae@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 13:35:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 13:35:35 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.551d4bb036fedbc2b6260ea8cf3c49ef@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"01809bcd4c9066244d705360f0d9a3a2176385f4/ghc" 01809bcd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01809bcd4c9066244d705360f0d9a3a2176385f4" Pass InScopeSet to substTy in lintTyApp This is the fix proposed in #11371: ``` In other cases, we already have the in-scope set in hand. Example: in CoreLint.lintTyApp we find a call to substTyWith. But Lint carries an in-scope set, so it would be easy to pass it to substTyWith. ``` Test Plan: ./validate --slow (only pre-existing problems) Reviewers: simonpj, goldfire, austin, nomeata, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1820 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 13:47:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 13:47:19 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.7f04754a13a2a4b0e06bb4b42621ae71@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): I'm not sure I completely understand your GHCi suggestion (but that is unnecessary) , but I certainly agree with the rest of your suggestions. If someone cares enough, they can fund the necessary engineering. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 14:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 14:51:42 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.f2e5ad46e1691182c186a2fb136ed2fe@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bheklilr): Replying to [comment:26 shubhaml]: > I'm willing to help @bheklilr with this. I'm a first-time contributor too. > > So far I've created a {{{--cleanup}}} flag which does exactly what {{{--make}}} does. I need to figure out the subsequent parts. > > One idea is that {{{hi}}} and {{{o}}} files will be deleted only if target directories are not specified using {{{-odir}}} and {{{-hidir}}} (since the target directories could be {{{/dev/null}}}). In this case these files are put in the same directory with the same name as the source file, and will be deleted. Other generated files from {{{-keep-*-files}}} will be preserved. > > So running with {{{ghc --cleanup}}} will, in effect, only create executables, and possibly some intermediate files other than {{{hi}}} and {{{o}}}. Is this a good idea? Also, have I missed something? I'm going to have to just pass this to you. I've been struggling with my home computer, trying to diagnose what appears to be hardware problems so I haven't had a stable computer for about a week now and won't for at least another week. Sorry to pass it on without having gotten any work done on it myself, this just hasn't been a good month for me, thanks for looking into it already =) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 15:11:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 15:11:49 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.8d51a5e5b7fd91ecd4a98ab05e1c95ff@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 15:15:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 15:15:31 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.93723918b148fbbb8b73a8c01e772beb@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Changes (by simonpj): * owner: => gmainland -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 15:16:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 15:16:28 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.a8e6faec3df72ab2a763da76463c48d1@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 15:16:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 15:16:47 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic In-Reply-To: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> References: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> Message-ID: <065.044cf0eb945dd67c051db557cb989c07@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 15:17:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 15:17:02 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.cfa8a8eb433598905b3757c2ff6c311d@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 15:46:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 15:46:20 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.e860b44ff82b5b6f4b6e159488be3b6b@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: I'm going to try my hand at this in my spare cycles. If it's blocking anyone feel free to grab it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 16:12:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 16:12:25 -0000 Subject: [GHC] #11494: Add -Wcompat to -Wall Message-ID: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> #11494: Add -Wcompat to -Wall -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 discussed in the call today we will add the `-Wcompat` warnings to `-Wall` pending discussion with the CLC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 16:24:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 16:24:47 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.1dd2eaf60d60dfc7cf052de552f91485@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by gmainland): Perhaps someone can volunteer to at least test? This appears to only manifest on ARM, and I don't have access to an ARM system. Would validate --slow on ARM catch this bug? From the bug report, it seems that perhaps the answer is "no." That should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 16:50:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 16:50:35 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.9143ccb94e8fafa2c7a0442360136b50@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by bgamari): I have an ARM box which I can test with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 16:58:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 16:58:11 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.8866e3922fdab997dac643d51ac0e697@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by gmainland): Great, can you also get a test into the testsuite that will detect this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:00:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:00:46 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.87f893c0258565852ede2ba286c384c9@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------- Comment (by bgamari): Do you know whether this is broken on the `ghc-8.0` branch as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:05:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:05:34 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.f72ca5a9ca5bc7f0fc7f5c4723bdf4e6@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by bgamari): Although sadly it seems I can't reproduce the issue on said machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:10:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:10:44 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.2f0de780db12690b7c1455591b97ded3@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------- Comment (by rwbarton): For me ghc-8.0 (from a few days ago) can bootstrap itself. There may be other variables here, like whether CPP is clang. I think the error means `MIN_VERSION_base(4,9,0)` was not expanded for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:11:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:11:52 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.e57e768e620d41f05daf683106914194@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by bgamari): I've proposed a testcase in Phab:D1851. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:13:54 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.70d2b014cb8933426c0b6de1564102f1@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by gmainland): I guess it will be difficult for you to test any proposed fix then :) Reid, can you help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:16:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:16:10 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 Message-ID: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- `TH_spliceE5_prof` looks like this: {{{ TH_spliceE5_prof:: $(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@ ./$@ }}} In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but **not** when compiling with `-dynamic`), so the second compilation results in: {{{ TH_spliceE5_prof.hs:8:17: fatal: cannot find object file ?./TH_spliceE5_prof_Lib.dyn_o? while linking an interpreted expression make[1]: *** [TH_spliceE5_prof] Error 1 *** unexpected failure for TH_spliceE5_prof(normal) }}} Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic`: {{{ Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interprter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. }}} Some ideas for a solution: * change that message to not mention `-dynamic` * always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic` * find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok. * make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff. It's all such a mess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:20:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:20:45 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.36374ae4f26041e3edc8ec479d22e13b@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by rwbarton): I think the reason that I only saw this bug with `-debug` is that the debug version of `stg_ap_ppp_fast` has extra code to print logging information when some debug flags are activated. This created enough register pressure that LLVM decided to rearrange some registers including `r8`, the ARM register that holds R2. Because `stg_ap_ppp_fast` invokes the function it calls with the R2 argument `undef`, once `r8` was clobbered, the invoked function saw the wrong value for R2, and a crash was inevitable. So here is a plan for testing for this bug, and others like it. * Add a flag `-fllvm-fill-undef-with-garbage`, and pass it when running validate. * In `Llvm.Types.ppLit`, if this flag is enabled, output `0xbbbbbbbb...` (of whatever size is needed) rather than `undef`. Then all LLVM builds should catch issues like this one. I can implement this if it sounds reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:21:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:21:28 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 In-Reply-To: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> References: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> Message-ID: <060.2d5e656c0e2527066aece39efa9e22a4@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 thomie: @@ -31,1 +31,2 @@ - `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic`: + `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic` is + necessary: New description: `TH_spliceE5_prof` looks like this: {{{ TH_spliceE5_prof:: $(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@ ./$@ }}} In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but **not** when compiling with `-dynamic`), so the second compilation results in: {{{ TH_spliceE5_prof.hs:8:17: fatal: cannot find object file ?./TH_spliceE5_prof_Lib.dyn_o? while linking an interpreted expression make[1]: *** [TH_spliceE5_prof] Error 1 *** unexpected failure for TH_spliceE5_prof(normal) }}} Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic` is necessary: {{{ Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interprter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. }}} Some ideas for a solution: * change that message to not mention `-dynamic` * always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic` * find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok. * make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff. It's all such a mess. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:24:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:24:00 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable In-Reply-To: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> References: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> Message-ID: <060.6b2996deddbd1ba3f38050b47b8be87a@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7149 | Differential Rev(s): Phab:D1849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6d2bdfd8d40b926d7a11d003213220022a63d9f5/ghc" 6d2bdfd8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d2bdfd8d40b926d7a11d003213220022a63d9f5" Fix segmentation fault when .prof file not writeable There are two ways to do retainer profiling. Quoting from the user's guide: 1. `+RTS -hr` "Breaks down the graph by retainer set" 2. `+RTS -hr -h`, where `-h` is one of normal heap profiling break-down options (e.g. `-hc`), and `-hr means "Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top." Retainer profiling writes to a .hp file, like the other heap profiling options, but also to a .prof file. Therefore, when the .prof file is not writeable for whatever reason, retainer profiling should be turned off completely. This worked ok when running the program with `+RTS -hr` (option 1), but a segfault would occur when using `+RTS -hr -h`, with `x!=r` (option 2). This commit fixes that. Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1849 GHC Trac Issues: #11489 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:25:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:25:33 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable In-Reply-To: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> References: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> Message-ID: <060.ece4ed57435903207f1e5bd87e323601@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7149 | Differential Rev(s): Phab:D1849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge Comment: Might as well merge this, although I don't think anyone will run into it soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:36:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:36:40 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.a009b71ad063dccfeefe32fd031bdcd1@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -----------------------------------+--------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------- Comment (by gmainland): Sounds reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:37:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:37:34 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.3259e185316329dcfce922fd48e05e9d@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott ): In [changeset:"6817703b31840620cca8596ca62ed70633934972/ghc" 6817703/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6817703b31840620cca8596ca62ed70633934972" Split off -Wunused-type-variables from -Wunused-matches Summary: Previously, `-Wunused-matches` would fire whenever it detected unused type variables in a type family or data family instance. This can be annoying for users who wish to use type variable names as documentation, as being `-Wall`-compliant would mean that they'd have to prefix many of their type variable names with underscores, making the documentation harder to read. To avoid this, a new warning `-Wunused-type-variables` was created that only encompasses unused variables in family instances. `-Wunused-matches` reverts back to its role of only warning on unused term-level pattern names. Unlike `-Wunused-matches`, `-Wunused-type-variables` is not implied by `-Wall`. Fixes #11451. Test Plan: ./validate Reviewers: goldfire, ekmett, austin, hvr, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1825 GHC Trac Issues: #11451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 17:46:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 17:46:52 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.56189c896b493e2ea2315568698fd4f2@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge Comment: I've updated [https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings Design/Warnings] to include the changes here and bring up the idea of `-Wpedantic`, if someone wants to implement that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 18:05:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 18:05:14 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.2 In-Reply-To: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> References: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> Message-ID: <061.f728e5125bb48d0bc4e4464329b66931@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 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 rwbarton): Does 8.2 need to be able to build with 7.10.1? If so then we can't remove these CPP guards entirely until 8.4. This is an honest question, by the way. I don't know whether our policy is that 8.2 should be buildable by ''every'' 7.10.* release, or ''some'' 7.10.* release, or perhaps the ''last'' 7.10.* release. If we somehow released a compiler that was completely incapable of bootstrapping GHC, it would be a serious problem for the "every" policy. Is this policy written down somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 18:11:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 18:11:34 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.0ed44af99e72b5094ac64b927f37da6b@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The status here is currently: * Visible type applications with -fhpc are fixed by the above patch for HEAD * Merged to 8.0 by d56d11ffff419875a1fc08e2ff470a5c8bd8785f * Richard is looking into redesigning the representation of visible type applications in HsExpr, I believe. Not absolutely critical for 8.0, but for the sake of GHC API users, better to change HsExpr once, than now and again in 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 18:12:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 18:12:23 -0000 Subject: [GHC] #7790: Add dummy undefined symbols to indicate ways In-Reply-To: <045.d04c5bfcd457784d65a81b621d13f03e@haskell.org> References: <045.d04c5bfcd457784d65a81b621d13f03e@haskell.org> Message-ID: <060.c3bc41cd2b07df7e716940125b678118@haskell.org> #7790: Add dummy undefined symbols to indicate ways -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Clever and simple, I like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 18:14:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 18:14:03 -0000 Subject: [GHC] #10324: our rts/ghc-prim/base shared library tricks don't work on Android In-Reply-To: <047.e2cf4a26e9b91cdd687dbdd933aadeb3@haskell.org> References: <047.e2cf4a26e9b91cdd687dbdd933aadeb3@haskell.org> Message-ID: <062.3761cb8028b44c6b3179632b7e3313f8@haskell.org> #10324: our rts/ghc-prim/base shared library tricks don't work on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #10352 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 19:17:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 19:17:22 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.fbb88146d974c910a4f75a7b6d3ed8dd@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------- Comment (by kgardas): Replying to [comment:1 bgamari]: > Do you know whether this is broken on the `ghc-8.0` branch as well? 8.0.1 RC1 seems to build 8.0.1 RC1 just fine on i386/solaris 11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 19:28:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 19:28:21 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.159af6fd5f86628604e55f9e56d566b8@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"144ddb414a8a4f40df1ad9ab27fcdf38f30db4d3/ghc" 144ddb41/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="144ddb414a8a4f40df1ad9ab27fcdf38f30db4d3" Construct in_scope set in mkTopTCvSubst The pre-condition on `mkTopTCvSubst` turned out to be wrong and not satisfied by any of the callers. I've fixed it, so that it constructs the in_scope set from the range of the substitution. `mkTopTCvSubst` was also unnecessarily general it is never called with `CoVars`, so I changed the type signature and added an assertion. Test Plan: ./validate --slow Reviewers: goldfire, simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1801 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 19:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 19:45:32 -0000 Subject: [GHC] #11496: Build profiling libraries on `validate --slow` Message-ID: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> #11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It would be good to test the `profiling` test ways regularly (`prof`, `profasm`, `profthreaded` etc.). These test ways require the profiling libraries to be built first, which `validate` doesn't do at the moment. We do release profiling libraries, so we'd better make sure they work correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 20:38:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 20:38:11 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.f4f2d79300249d7febb4b1dc2fb12c75@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+--------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------- Comment (by kgardas): verified that today's head is still not able to build the same head. At least not on Solaris 11/i386 platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 21:49:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 21:49:18 -0000 Subject: [GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE Message-ID: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> #11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature | Status: new request | Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Keywords: LAMBORGHINI | Operating System: MacOS X MANYLINE JOINT SHARE | Architecture: Other | Type of failure: Other Test Case: none | Blocked By: Blocking: | Related Tickets: no Differential Rev(s): no | Wiki Page: none -------------------------------------+------------------------------------- http://lamborghini.com [[Image(link company_profile_1800x405.kamaljit.jpg )]] * '''bold''', ''' myself a worker in this company : THIS THE COMPANY WEBSITE ADDRESS ''', * ''italic'' * '''''VIA MODENA 12,40019,SAN'T AGATA BOLOGNESE [B0]''''' or ''italic and ''' italic bold ''' '' * __LAMBORGHINI MANYLINE JOINT SHARE__ * {{{schoolbook century}}} or `monospace` (hence ` RESPECTED FERRUCCIO LAMBORGHINI` or {{{:LAMBORGHINI}}} quoting `{{{VAT ID:00591801204 wire with ||:ICIC0002790}}} quoting) * ~~strike-through KAMALJITCHAKRABORTY~~ * ^LAMBORGHINI AUTOMOBILI S.p.A^ * ,,subscript,, * **RESPECTED STEPHAN WINKELMANN**, //**RESPECTED PATRICK KUJALA as well**//,**SRI SUSIT KUMAR CHAKRABARTI**, and **'' bold italic **'' //(since 0.40)// [[Image(thumb_IMG_0216_1024.jpg)]] * {{{Item}}} 1CK: Friday, February 19th, 2016 - Monday, February 22nd, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 1 }}} * Item 1.1 * Item 1.1.1 * Item 1.1.2 * Item 1.1.3 * Item 1.2 * {{{Item}}} 2CK: Sunday, February 21st, 2016 - Wednesday, February 24th, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 2 }}} * Item 2.2.1 * Item 2.2.2 * Item 2.2.3 * {{{Item}}} 3CK:Tuesday, February 23rd, 2016 - Friday, February 26th, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 3}}} * Item 3.3.1 * Item 3.3.2 * Item 3.3.3 * {{{Item}}} 4CK: Thursday, February 25th, 2016 - Saturday, February 27th, 2016 {{{WINTER ACCADEMIA LIVIGNO - INTENSIVO 1}}} * Item 4.4.1 * Item 4.4.2 * Item 4.4.3 - items can start at the beginning of a line and they can span multiple lines - be careful though to continue the line with the appropriate indentation, otherwise that will start a new paragraph... 1. Item 1 a. Item 1.a a. Item 1.b i. Item 1.b.i i. Item 1.b.ii 1. Item 2 And numbered lists can also be restarted with an explicit number: 3. Item 3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 21:49:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 21:49:41 -0000 Subject: [GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE In-Reply-To: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> References: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> Message-ID: <073.c4d020fd00e0abffb26cf8aeb984dc8a@haskell.org> #11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature request | Status: new Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Resolution: | Keywords: LAMBORGHINI | MANYLINE JOINT SHARE Operating System: MacOS X | Architecture: Other Type of failure: Other | Test Case: none Blocked By: | Blocking: Related Tickets: no | Differential Rev(s): no Wiki Page: none | -------------------------------------+------------------------------------- Changes (by kamaljitchakraborty): * Attachment "thumb_IMG_0216_1024.jpg" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 21:50:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 21:50:02 -0000 Subject: [GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE In-Reply-To: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> References: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> Message-ID: <073.b0def46437f0497819bae612f054e455@haskell.org> #11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature request | Status: new Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Resolution: | Keywords: LAMBORGHINI | MANYLINE JOINT SHARE Operating System: MacOS X | Architecture: Other Type of failure: Other | Test Case: none Blocked By: | Blocking: Related Tickets: no | Differential Rev(s): no Wiki Page: none | -------------------------------------+------------------------------------- Changes (by kamaljitchakraborty): * Attachment "company_profile_1800x405.kamaljit.jpg" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 21:54:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 21:54:09 -0000 Subject: [GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE In-Reply-To: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> References: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> Message-ID: <073.d4089a174c5c505baec76f38f823688e@haskell.org> #11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature request | Status: infoneeded Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Resolution: | Keywords: LAMBORGHINI | MANYLINE JOINT SHARE Operating System: MacOS X | Architecture: Other Type of failure: Other | Test Case: none Blocked By: | Blocking: Related Tickets: no | Differential Rev(s): no Wiki Page: none | -------------------------------------+------------------------------------- Changes (by kamaljitchakraborty): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 22:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 22:00:42 -0000 Subject: [GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE In-Reply-To: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> References: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> Message-ID: <073.c4d020fd00e0abffb26cf8aeb984dc8a@haskell.org> #11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature request | Status: infoneeded Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Resolution: | Keywords: LAMBORGHINI | MANYLINE JOINT SHARE Operating System: MacOS X | Architecture: Other Type of failure: Other | Test Case: none Blocked By: | Blocking: Related Tickets: no | Differential Rev(s): no Wiki Page: none | -------------------------------------+------------------------------------- Changes (by kamaljitchakraborty): * Attachment "thumb_IMG_0216_1024.jpg" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 22:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 22:00:42 -0000 Subject: [GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE In-Reply-To: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> References: <058.92e6c0ed4ec2da16eb9991ccf1a3278e@haskell.org> Message-ID: <073.b0def46437f0497819bae612f054e455@haskell.org> #11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature request | Status: infoneeded Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Resolution: | Keywords: LAMBORGHINI | MANYLINE JOINT SHARE Operating System: MacOS X | Architecture: Other Type of failure: Other | Test Case: none Blocked By: | Blocking: Related Tickets: no | Differential Rev(s): no Wiki Page: none | -------------------------------------+------------------------------------- Changes (by kamaljitchakraborty): * Attachment "company_profile_1800x405.kamaljit.jpg" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 26 23:43:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jan 2016 23:43:49 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.1f43ca26298180fe53b658a48f8a88aa@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): +1 a good idea, will make existing books etc more useable with the latest software -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 00:55:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 00:55:57 -0000 Subject: [GHC] #11496: Build profiling libraries on `validate --slow` In-Reply-To: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> References: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> Message-ID: <060.127e395e2dabc0d9a2dd73cd13ba30ca@haskell.org> #11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"eeb67c9b833d95fa69932c34a3175054dacb83e2/ghc" eeb67c9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eeb67c9b833d95fa69932c34a3175054dacb83e2" Testsuite: fixup req_profiling tests (#11496) * T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof. * TH_spliceE5_prof (#11495) is failing when ghc_dynamic * Rename ghci_dynamic to ghc_dynamic. It's the same thing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 00:55:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 00:55:57 -0000 Subject: [GHC] #10037: Several profiling tests give different results optimised vs. unoptimised In-Reply-To: <047.efcb9e013309246f2cfca887b5137899@haskell.org> References: <047.efcb9e013309246f2cfca887b5137899@haskell.org> Message-ID: <062.ad640a5d79887dc0484901da7948e295@haskell.org> #10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"eeb67c9b833d95fa69932c34a3175054dacb83e2/ghc" eeb67c9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eeb67c9b833d95fa69932c34a3175054dacb83e2" Testsuite: fixup req_profiling tests (#11496) * T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof. * TH_spliceE5_prof (#11495) is failing when ghc_dynamic * Rename ghci_dynamic to ghc_dynamic. It's the same thing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 00:55:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 00:55:57 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 In-Reply-To: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> References: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> Message-ID: <060.3ea3c4146c7d46c17bf7c8485ebf6da1@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 Thomas Miedema ): In [changeset:"eeb67c9b833d95fa69932c34a3175054dacb83e2/ghc" eeb67c9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eeb67c9b833d95fa69932c34a3175054dacb83e2" Testsuite: fixup req_profiling tests (#11496) * T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof. * TH_spliceE5_prof (#11495) is failing when ghc_dynamic * Rename ghci_dynamic to ghc_dynamic. It's the same thing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 00:55:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 00:55:57 -0000 Subject: [GHC] #11496: Build profiling libraries on `validate --slow` In-Reply-To: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> References: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> Message-ID: <060.9c682e26f6c08b6068a3b890553ac34f@haskell.org> #11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"e2bdf03a63b09feabee76e2efd33eb56739324ac/ghc" e2bdf03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2bdf03a63b09feabee76e2efd33eb56739324ac" Build profiling libraries on `validate --slow` (#11496) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 00:56:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 00:56:56 -0000 Subject: [GHC] #11496: Build profiling libraries on `validate --slow` In-Reply-To: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> References: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> Message-ID: <060.b5e1340bba4748d0fc9f8aa4330de81c@haskell.org> #11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.0.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 thomie): * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 02:59:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 02:59:55 -0000 Subject: [GHC] #11498: GHC requires kind-polymorphic signatures on class head Message-ID: <047.c869cb625243c8891f031146b4e58720@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 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 have the following compiling example: {{{ {-# LANGUAGE DataKinds, FlexibleContexts, FlexibleInstances, KindSignatures, MultiParamTypeClasses, PolyKinds, RankNTypes, ScopedTypeVariables, TypeFamilies, TypeOperators #-} import Data.Proxy import GHC.Prim type family CtxOf d (args :: k) :: Constraint class Run ctx (params :: [k]) where runAll :: Proxy params -> Proxy ctx -> (forall (args :: k) . (CtxOf ctx args) => Proxy args -> Bool) -> [Bool] data BasicCtxD type instance CtxOf BasicCtxD '(a,b) = (a ~ b) instance (Run BasicCtxD params, a ~ b) => Run BasicCtxD ( '(a,b) ': params) where runAll _ pctx f = (f (Proxy::Proxy '(a,b))) : (runAll (Proxy::Proxy params) pctx f) }}} But if I move the kind signature of `params` to its occurrence in the signature of `runAll`: {{{ class Run ctx params where runAll :: Proxy (params :: [k]) -> Proxy ctx -> (forall (args :: k) . (CtxOf ctx args) => Proxy args -> Bool) -> [Bool] }}} I get a couple of nasty (and confusing) compile errors. {{{ Main.hs:20:25: Couldn't match kind ?k1? with ?(,) k k? ?k1? is a rigid type variable bound by the type signature for runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] at Main.hs:20:3 Expected type: Proxy args0 Actual type: Proxy '(a, b) Relevant bindings include f :: forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool (bound at Main.hs:20:17) runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] (bound at Main.hs:20:3) In the first argument of ?f?, namely ?(Proxy :: Proxy '(a, b))? In the first argument of ?(:)?, namely ?(f (Proxy :: Proxy '(a, b)))? In the expression: (f (Proxy :: Proxy '(a, b))) : (runAll (Proxy :: Proxy params) pctx f) Main.hs:21:42: Could not deduce (k1 ~ (,) k k) from the context (CtxOf BasicCtxD args) bound by a type expected by the context: CtxOf BasicCtxD args => Proxy args -> Bool at Main.hs:21:8-42 ?k1? is a rigid type variable bound by the type signature for runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] at Main.hs:20:3 Expected type: Proxy args -> Bool Actual type: Proxy args1 -> Bool Relevant bindings include f :: forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool (bound at Main.hs:20:17) runAll :: Proxy ('(a, b) : params) -> Proxy BasicCtxD -> (forall (args :: k1). CtxOf BasicCtxD args => Proxy args -> Bool) -> [Bool] (bound at Main.hs:20:3) In the third argument of ?runAll?, namely ?f? In the second argument of ?(:)?, namely ?(runAll (Proxy :: Proxy params) pctx f)? }}} It seems to me that the two definitions of the class are equivalent, so it would be nice if they both compiled. It wasn't obvious to me that the kind signature had to go on the class parameter rather than somewhere else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 05:12:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 05:12:41 -0000 Subject: [GHC] #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan In-Reply-To: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> References: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> Message-ID: <065.d27d7ae2ea0550658d8d620f195477ed@haskell.org> #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan ---------------------------------+---------------------------------------- Reporter: hienqnguyen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 hienqnguyen): Nope, it doesn't not. On my iMac (also with El Capitan), I had ghc 7.10.2 installed and when I ran the same 'stack upgrade' command it seemed fine. It downloaded 7.10.3, all the deps, then compiled stack from source w/o any issues. Perhaps, my macbook env is corrupt somehow... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 05:25:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 05:25:29 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi Message-ID: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> #11499: Loading temp shared object failed in GHCi --------------------------------------+------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- While trying to launch ghci got the following error: ? stack ghci The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc23900_0/libghc_25.dylib 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 Wed Jan 27 06:06:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 06:06:21 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.cc4107da86ca9edf85c1d5b4a23dda54@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D1858 * os: Linux => Unknown/Multiple * architecture: arm => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 07:06:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 07:06:59 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.2d6a091e00626cdbcf464c92492c5a79@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Changes (by trommler): * status: new => infoneeded * keywords: => dynamic linking * related: => #10458 Comment: Thanks for the report. This looks like the same issue as #10458, which is fixed in HEAD and the tip of ghc-8.0 but not RC1. Could you try with one of those and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 07:07:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 07:07:26 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.40143f0dafc1258a702508e1f447b543@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 09:32:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 09:32:20 -0000 Subject: [GHC] #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down Message-ID: <046.cb72d039f3ebee049133c126d9202162@haskell.org> #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down -------------------------------------+------------------------------------- Reporter: skydust | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | 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 C finalizer of a ForeignPtr that was explicitly finalized (finalizeForeignPtr) is sometimes called again when the RTS shuts down. Expected behaviour: - The test script (./test.sh) below never stops Observed behaviour: - After a while, the test script stops with an error message indicating double free or memory corruption {{{#!sh $ ./test.sh }}} {{{ [1 of 1] Compiling Main ( finalizer_hs.hs, finalizer_hs.o ) Linking finalizer_hs ... *** Error in `./finalizer_hs': double free or corruption (!prev): 0x00000000010b85e0 *** ./test.sh: line 3: 20482 Aborted (core dumped) ./finalizer_hs +RTS -N 178 }}} File finalizer_hs.hs {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} import Foreign (Ptr, FunPtr, malloc) import Foreign.ForeignPtr (newForeignPtr, finalizeForeignPtr) import Control.Monad (forM, forM_) foreign import ccall "stdlib.h &free" p_free :: FunPtr (Ptr a -> IO ()) main :: IO () main = do fps <- forM [1 .. 10000] $ \_ -> do p <- malloc newForeignPtr p_free (p :: Ptr Int) forM_ fps finalizeForeignPtr }}} File test.sh: {{{#!sh ghc finalizer_hs.hs -threaded CNT=0 while ./finalizer_hs +RTS -N; do CNT=$((CNT+1)); done echo $CNT }}} Note: running several instances of ./test.sh concurrently triggers the problem faster Issue detected on following tested setups: - Linux 32bit GHC 7.10.2 - Linux 64bit GHC 7.8.3 - Linux 64bit GHC 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 09:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 09:51:50 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.93a04ec72467916f248b5df29e729bad@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"44a5d51a4892b85c7eba09dcb90ca02245637812/ghc" 44a5d51a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44a5d51a4892b85c7eba09dcb90ca02245637812" Enable RemoteGHCi on Windows Makes the needed changes to make RemoteGHCi work on Windows. The approach passes OS Handles areound instead of the Posix Fd as on Linux. The reason is that I could not find any real documentation about the behaviour of Windows w.r.t inheritance and Posix FDs. The implementation with Fd did not seem to be able to find the Fd in the child process. Instead I'm using the much better documented approach of passing inheriting handles. This requires a small modification to the `process` library. https://github.com/haskell/process/pull/52 Test Plan: ./validate On Windows x86_64 Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr Reviewed By: simonmar Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1836 GHC Trac Issues: #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 09:53:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 09:53:53 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.a98e3566b407f0a511aacd3e88f9d2ab@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: merge Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 09:54:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 09:54:59 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.bc62b3e248b9bf4bbe0f1128f64f79a7@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"45fd83bb5ed3a66320eb873039b65566f53ed36a/ghc" 45fd83b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45fd83bb5ed3a66320eb873039b65566f53ed36a" Fix a typo in the note name in comments This is `subsititution` to `substitution`, plus one instance of the note that I missed. Test Plan: docufix Reviewers: simonpj, bgamari, austin, goldfire Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1856 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:03:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:03:02 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.159dafa7eac7dc40c83876df7c193d40@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): This looks terribly suspicious (in `TyCoRep`): {{{ extendSubstEnvs :: (TvSubstEnv, CvSubstEnv) -> Var -> Type -> (TvSubstEnv, CvSubstEnv) extendSubstEnvs (tenv, cenv) v ty | isTyVar v = ASSERT( not $ isCoercionTy ty ) (extendVarEnv tenv v ty, cenv) -- NB: v might *not* be a proper covar, because it might be lifted. -- This happens in tcCoercionToCoercion | CoercionTy co <- ty = (tenv, extendVarEnv cenv v co) | otherwise = pprPanic "extendSubstEnvs" (ppr v <+> text "|->" <+> ppr ty) }}} I think that the `Var` passed to `extendSubsEnv` should be a proper `TyVar` or a `CoVar`. Moreover `tcCoercionToCoercion` doesn?t exist. Is the comment now out of date? I hope so. Moreover, it seems suspicious to pattern match on `CoercionTy`. What if there was a type synonym in the way? Or a cast? HOWEVER, we do need to get the coercion out to put into `cenv`. But that makes me suspicious too. I think that almost all calls to `extendSubstEnvs` provide only `TyVars`, not `CoVars`. The only call I can find that doesn?t is in `TcMType.instSkolTyCoVarX`, which tests the variable, and makes a `CoercionTy` ? only for `extendTCvSubst` to unpack it again. Concretely, I suggest that * we rename `extendTCvSubst` to be `extendTvSubst`, and work only over `TyVars`. (Have an assertion of course.) * have a similar one for `extendCvSubst` and see how that goes. It?s be in line with the new `zipTvSubst`, `zipCvSubst` etc. Richard, can you see anything wrong with that? Bartosz, might you execute? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:12:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:12:03 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.28e8342383cf6444ac577294056d45f9@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): While I'm thinking about this, I'd like to get rid of `composeTCvSubst`. It is somewhat complex, but it is used in very simple ways, basically as a form of `extendTCvSubst`. For example this call (in `checkAxInstCo`) is just stupid {{{ subst = zipTvSubst tvs tys `composeTCvSubst` zipCvSubst cvs co_args }}} There are very few calls altogether. I think it could easily be nuked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:29:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:29:01 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.fdf7b7e610db87379ea33d4d1b016a73@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This fails, {{{#!hs {-# LANGUAGE DataKinds #-} import Data.Typeable import Data.Functor.Compose main :: IO () main = print $ typeOf (undefined :: Proxy 'Compose) }}} with a compiler panic due to `TcInteract.mk_typeable_pred` calling `typeKind` on an ill-kinded type, `TYPE 'Lifted (TYPE 'Lifted *) -> Compose * * *`. Note the application `TYPE 'Lifted (TYPE 'Lifted *)`, which oversaturates `TYPE`. The problem here is apparently that the kind variables of `Compose` are all instantiated with `*` with `-XNoPolyKinds` I haven't yet determined where this occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:30:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:30:51 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.d6daeacdbee7e4e1ee0dd3324dbec83b@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f6d1422f9fe875e1d150b423c4864b42d96b8db/ghc" 1f6d1422/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f6d1422f9fe875e1d150b423c4864b42d96b8db" ghci: fix trac issue #11481 Test Plan: validate Reviewers: thomie, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1833 GHC Trac Issues: #11481 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:30:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:30:51 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.8839dcb1f82d604826b7fe2261e19f54@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822, Wiki Page: | Phab:D1844 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1c6130d91420dc835c281bc9b13d603b7aa49b59/ghc" 1c6130d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c6130d91420dc835c281bc9b13d603b7aa49b59" rts/Timer: Actually fix #9105 jberthold astutely pointed out that the previous fix (D1822) could not have possibly fixed the issue as the patch would only have had any effect if !PROFILING. Test Plan: Check for reduced CPU usage when compiled with `-prof` but without `+RTS -p` Reviewers: simonmar, austin, jberthold Reviewed By: simonmar, jberthold Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1844 GHC Trac Issues: #9105 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:30:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:30:51 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.4a6e6766b4ca630e40b8ff95769f3df9@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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:D1847 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6/ghc" 0dc7b36c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6" Restore original alignment for info tables This was broken in 4a32bf925b8aba7885d9c745769fe84a10979a53, meaning that info tables and subsequent code are no longer guaranteed to have the recommended alignment. Split up the section header and section alignment printers, and print an appropriate alignment directive before each info table. Fixes Trac #11486 Reviewers: austin, bgamari, rwbarton Reviewed By: bgamari, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1847 GHC Trac Issues: #11486 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:30:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:30:51 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.5b8888e4c3ed020cf2d636cd83e5454e@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d50609e8f7a9c3a19d9d75c6133e742c9b584732/ghc" d50609e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d50609e8f7a9c3a19d9d75c6133e742c9b584732" Test for undef bugs in the LLVM backend when validating In an attempt to catch bugs involving using undef values, replace undef literals by values likely to cause crashes or test failures. We do this only when validating since it is a deoptimization. This depends on D1857 to catch such bugs in the RTS (such as #11487). Test Plan: Did a build with ``` BuildFlavour = quick-llvm SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage ``` The build crashed when running ghc-stage2, as expected. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:32:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:32:03 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.66905f018506d2c0b4a4e1dac29b629e@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe this is happening in `TcMType.quantifyTyVars`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:59:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:59:15 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.f3972b4deed10d75c5a0bcaa881fce31@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 10:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 10:59:21 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.038ab95d7c0a164504e0997ac362a851@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822, Wiki Page: | Phab:D1844 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:07:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:07:13 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.0da7126f68032b14d0d9341c18dcbb02@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as c4e94cd3f1742cc5e2b8391d151fef2fc9f8fdbe and f47feda9c1a5298fbcf40a5aba87750d19e14157. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:08:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:08:52 -0000 Subject: [GHC] #11489: Segmentation fault when .prof file not writeable In-Reply-To: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> References: <045.292cbcf9039c57c71bcfd4867616abe4@haskell.org> Message-ID: <060.6a3e35ed66438a47012724c773b1d0b2@haskell.org> #11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7149 | Differential Rev(s): Phab:D1849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 8efe964a0f31af30c5b860b7491f4f278884493b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:09:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:09:16 -0000 Subject: [GHC] #11451: Inconsistent warnings for unused binders in type and instance declarations In-Reply-To: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> References: <046.a2575e2dc3c3459a0cd8447918db6b6d@haskell.org> Message-ID: <061.b0bf76fb28481fc878f98931cffabf24@haskell.org> #11451: Inconsistent warnings for unused binders in type and instance declarations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | 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): Phab:D1825 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 2d3f277817b3a173a5651fc8d10601851485302f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:09:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:09:45 -0000 Subject: [GHC] #11496: Build profiling libraries on `validate --slow` In-Reply-To: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> References: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> Message-ID: <060.1cac84257311768efbc3c9d89780de0f@haskell.org> #11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as f5ccb528dfd078e34cd0041f9a0ee56884677351. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:09:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:09:57 -0000 Subject: [GHC] #11496: Build profiling libraries on `validate --slow` In-Reply-To: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> References: <045.8ca835b0a9d77ce2022c960e123634c4@haskell.org> Message-ID: <060.3c8ea3a03ba05e3a0bd920d1ff402c7d@haskell.org> #11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.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 bgamari): and 7c6215bc7d25e47d2753c46980bd8e4600d11cc6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:10:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:10:16 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.6577aad901e237ea078a87323efda6bb@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 0e90d3bded49f42d25527cd4a67f2b1ef9cf5ff3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:10:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:10:34 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.dc2a6b5f5ea943d351a0fe92ffff0725@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as e17a1d5700801db97d10e4bbdd8b31080bba47dc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:10:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:10:52 -0000 Subject: [GHC] #9105: Profiling binary consumes CPU even when idle on Linux. In-Reply-To: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> References: <045.aece9695e43fc7ec82efb4dd7bee64b4@haskell.org> Message-ID: <060.9c89d5aa6f8be43adb69d2c244cd15de@haskell.org> #9105: Profiling binary consumes CPU even when idle on Linux. -------------------------------------+------------------------------------- Reporter: robinp | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1822, Wiki Page: | Phab:D1844 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 7d123cc87ba69d96f4e32921549201537abe118b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:11:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:11:15 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.198f71ba86ac4e60e7ce75d4776599cc@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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:D1847 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 12:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 12:11:27 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.bcb332acae734ad95fcdfa855ae7c2fc@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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:D1847 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 7a70f980d39533f30e1a6504b7821e63a4d6f41e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 13:03:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 13:03:35 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.57d42bd9638d86e4ca40f1249568c9eb@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Thanks triple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:08:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:08:56 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.5858053cd76db66cf279469439a76a71@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:16 simonpj]: > Richard, can you see anything wrong with that? Not at all. I very nearly did that myself a while ago, but it meant some code duplication around `instSkolTyCoVarX` (and perhaps one other place, if memory serves -- I'm sure you'll find it by looking at use sites of `extendTCvSubst`). Yes -- go for it. This is an improvement. The comment about `tcCoercionToCoercion` is historical and should be removed, along with that case, which should indeed never be triggered now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:15:34 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.7cba0d40bc24861f91e0ce861d5c6411@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh dear. Something seems terribly terribly wrong. {{{#!hs newtype Compose (f :: k -> *) (g :: k1 -> k) (a :: k1) = Compose {getCompose :: f (g a)} }}} This gives `Compose :: forall k k1. (k -> *) -> (k1 -> k) -> k1 -> *`. But your code above has '''three''' `*`s passed to `Compose`. Somehow the third one is wrong. (I think the first two are correct, as set in `quantifyTyVars`. I'm unconvinced that `quantifyTyVars` is to blame.) GHC is getting duped into thinking `* :: * -> *`, which would, actually, make the `TYPE 'Lifted (TYPE 'Lifted *)` bit well kinded. I've no clue where this is going wrong, but it's going wrong rather spectacularly. My next step would be `-ddump-tc-trace -fprint-explicit- kinds` and search for the first occurrence of `Compose * * *`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:33:12 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application In-Reply-To: <046.9e988e804957302749d23e8054557bb0@haskell.org> References: <046.9e988e804957302749d23e8054557bb0@haskell.org> Message-ID: <061.101db151c47ff86df2a2fab8fcbdeea2@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"00cbbab3362578df44851442408a8b91a2a769fa/ghc" 00cbbab3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00cbbab3362578df44851442408a8b91a2a769fa" Refactor the typechecker to use ExpTypes. The idea here is described in [wiki:Typechecker]. Briefly, this refactor keeps solid track of "synthesis" mode vs "checking" in GHC's bidirectional type-checking algorithm. When in synthesis mode, the expected type is just an IORef to write to. In addition, this patch does a significant reworking of RebindableSyntax, allowing much more freedom in the types of the rebindable operators. For example, we can now have `negate :: Int -> Bool` and `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic is in tcSyntaxOp. This addresses tickets #11397, #11452, and #11458. Tests: typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458} th/T11452 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:33:12 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.1ce84c5bfdfbcd5517f3a8b71055a2c2@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2899aa580d633103fc551e36c977720b94f5b41c/ghc" 2899aa5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2899aa580d633103fc551e36c977720b94f5b41c" Fix some substitution InScopeSets This is relevant to #11371. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:33:12 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.724b65637397915ebef725ca4e1826de@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"00cbbab3362578df44851442408a8b91a2a769fa/ghc" 00cbbab3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00cbbab3362578df44851442408a8b91a2a769fa" Refactor the typechecker to use ExpTypes. The idea here is described in [wiki:Typechecker]. Briefly, this refactor keeps solid track of "synthesis" mode vs "checking" in GHC's bidirectional type-checking algorithm. When in synthesis mode, the expected type is just an IORef to write to. In addition, this patch does a significant reworking of RebindableSyntax, allowing much more freedom in the types of the rebindable operators. For example, we can now have `negate :: Int -> Bool` and `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic is in tcSyntaxOp. This addresses tickets #11397, #11452, and #11458. Tests: typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458} th/T11452 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:33:12 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity In-Reply-To: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> References: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> Message-ID: <062.486364f97ff225a2479ee9b7020b8fc0@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Richard Eisenberg ): In [changeset:"00cbbab3362578df44851442408a8b91a2a769fa/ghc" 00cbbab3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00cbbab3362578df44851442408a8b91a2a769fa" Refactor the typechecker to use ExpTypes. The idea here is described in [wiki:Typechecker]. Briefly, this refactor keeps solid track of "synthesis" mode vs "checking" in GHC's bidirectional type-checking algorithm. When in synthesis mode, the expected type is just an IORef to write to. In addition, this patch does a significant reworking of RebindableSyntax, allowing much more freedom in the types of the rebindable operators. For example, we can now have `negate :: Int -> Bool` and `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic is in tcSyntaxOp. This addresses tickets #11397, #11452, and #11458. Tests: typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458} th/T11452 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:37:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:37:32 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application In-Reply-To: <046.9e988e804957302749d23e8054557bb0@haskell.org> References: <046.9e988e804957302749d23e8054557bb0@haskell.org> Message-ID: <061.83270223775c7b93f7cb8c871c16b2ac@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11458 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T11458 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:37:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:37:59 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.abd0694f0ccb0495c28262c1cf4a842a@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compiler/T11397 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compiler/T11397 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:38:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:38:20 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity In-Reply-To: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> References: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> Message-ID: <062.db3cc1ce4fa518781345d0236ea7f7d3@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T11452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => th/T11452 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:39:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:39:38 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.49e6cc15c7c238e398213d2abea5c912@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by goldfire): I'm a little lost in these substitutions, but I had to fix this one case to get some sample code to compile. The commit above should be merged to the stable branch, but it doesn't fully solve this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 14:40:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 14:40:11 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application In-Reply-To: <046.9e988e804957302749d23e8054557bb0@haskell.org> References: <046.9e988e804957302749d23e8054557bb0@haskell.org> Message-ID: <061.460a5a0c2d8aee7de920f96d773e7072@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11458 Blocked By: | Blocking: Related Tickets: #11397 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * related: => #11397 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 15:16:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 15:16:06 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.c84aa74605ed07108b3eaeabf40faa5f@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"5dcae88bd0df440abe78c3d793d21aca6236fc25/ghc" 5dcae88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5dcae88bd0df440abe78c3d793d21aca6236fc25" Rename "open" subst functions This is the renaming that @simonpj requested: ``` ? zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars) ? zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with covars) ? zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals with TyBinders, not covars) ``` plus the `mk` variant. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D1853 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 15:19:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 15:19:47 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.981a5ade5c4dbeca7713071f01e8fe7a@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"85daac593c498f581d46f44982ee5dcf1001f611/ghc" 85daac5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85daac593c498f581d46f44982ee5dcf1001f611" Fix cost-centre-stack bug when creating new PAP (#5654) See comment in `AutoApply.h`. This partly fixes #5654. New test added, and renamed the old test to match the ticket number. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 15:29:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 15:29:38 -0000 Subject: [GHC] #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down In-Reply-To: <046.cb72d039f3ebee049133c126d9202162@haskell.org> References: <046.cb72d039f3ebee049133c126d9202162@haskell.org> Message-ID: <061.d4100577aaf7b4871d8577026d3f9aa6@haskell.org> #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down -------------------------------------+------------------------------------- Reporter: skydust | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.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 simonmar): dup of #7170; the fix is in 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 15:29:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 15:29:50 -0000 Subject: [GHC] #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down In-Reply-To: <046.cb72d039f3ebee049133c126d9202162@haskell.org> References: <046.cb72d039f3ebee049133c126d9202162@haskell.org> Message-ID: <061.8c7e4f3f67ddf8656b6f652f48d5abc0@haskell.org> #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down -------------------------------------+------------------------------------- Reporter: skydust | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | 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 simonmar): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 15:38:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 15:38:25 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 In-Reply-To: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> References: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> Message-ID: <060.388248ab003ce6b2b629fa338b383de0@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): > It's all such a mess. Yup. I guess we should not put `-dynamic` in `ghcThWayFlags`, because (a) it doesn't work with `-prof` and (b) It is sort-of handled magically by GHC turning on `-dynamic-too` when we need TH. This crap is part of the reason I wanted to make `-fexternal-interpreter`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 16:09:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 16:09:12 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied Message-ID: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.10.3 benchmark suite | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building nofib/fibon returns permission denied: {{{ == make boot - --no-print-directory; in /h/ywang30/nofib/fibon/Hackage/Bzlib ------------------------------------------------------------------------ // Codec/Compression/BZip/Stream.hsc make[3]: execvp: //: Permission denied make[3]: *** [Codec/Compression/BZip/Stream.hs] Error 127 }}} Steps to reproduce: Edit nofib/mk/boilerplate.mk:35 to NoFibSubDirs = fibon make clean && make boot in nofib/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 16:28:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 16:28:23 -0000 Subject: [GHC] #11357: Regression when deriving Generic1 on poly-kinded data family In-Reply-To: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> References: <050.901cd59cca6d2d30c1ece6815b80ca65@haskell.org> Message-ID: <065.4ade067bc515cd361d53ba278ceefdfc@haskell.org> #11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Generics, Resolution: | TypeInType, 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): * cc: aaditmshah@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 17:31:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 17:31:20 -0000 Subject: [GHC] #11481: New GHCi command `:load!` doesn't defer typed holes In-Reply-To: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> References: <045.227b5e8267b11a99216f653f03d759e4@haskell.org> Message-ID: <060.18aada077350550db46908e4b3244ab4@haskell.org> #11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: triple Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | 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: #9497 | Differential Rev(s): Phab:D1833 Wiki Page: | -------------------------------------+------------------------------------- Comment (by triple): You are welcome. Sorry for the Phabricator trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 17:56:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 17:56:19 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.74228fca4db95d898cbad1d2d2fe7a86@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Commit that nomeata mentioned in comment:10 (Phab:D1821 actually): commit f42db1574935b088cfc13cca7c935990002651dc {{{ Author: Joachim Breitner Date: Sat Jan 23 13:12:10 2016 +0100 Remove unused IND_PERM it seems that this closure type has not been in use since 5d52d9, so all this is dead and untested code. This removes it. Some of the code might be useful for a counting indirection as described in #10613, so when implementing that, have a look at what this commit removes. Test Plan: validate on harbormaster Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1821 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 19:05:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 19:05:06 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.67df24358a3b2cb87341aed668bb738f@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer 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 bollmann): It seems that this issue was already fixed in ticket #10734. I just added the above test locally and it passes in the current head: https://git.haskell.org/ghc.git/commitdiff/00cbbab3362578df44851442408a8b91a2a769fa. Shall I add the above testcase as part of the TH testsuite and then close the ticket? Or shall we just close this ticket right away? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 19:14:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 19:14:02 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.db891c26dc64e74a13d8ef556ab70f09@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by jscholl): I could halfway reproduce this: The following program has an intermediate state where a value ({{{arr2}}}) is marked with {{{}}} which is later used again (in the unfolding of {{{getIt}}}). This does however not completely trigger the bug as {{{arr2}}} gets marked too early, i.e. worker-wrapper is not yet running. Then the simplifier inlines {{{getIt}}} and {{{arr2}}} is referenced again, so when worker-wrapper runs everything has the correct strictness. However, if I somehow could convince the compiler to run the worker- wrapper transformation before phase 0 the program has a good chance to trigger the bug. Even if it does not, I think the usage of {{{arr2}}} should not be {{{}}} as it could be still referenced if {{{getIt}}} is inlined. I used the following command to generate the core2core log (ghc 7.10.3): {{{ghc -c Unfold.hs -ddump-simpl -dsuppress-coercions -dsuppress-type- applications -dsuppress-uniques -dsuppress-module-prefixes -dverbose- core2core -O -fstrictness-before=0}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 19:14:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 19:14:55 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.1232cbc11c04e6d415bbcd7ed538b2b3@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): * Attachment "Unfold.hs" added. program with wrong intermediate usage annotation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 19:15:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 19:15:23 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.2e2917d37f6903a2d6e8168b2b6e4e9e@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 jscholl): * Attachment "UnfoldDump" added. core2core log when compiling Unfold.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 20:06:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 20:06:01 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.0d54ad3ad3972618b540fcc52c561689@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): **Disclaimer**: The following commentary is dangerously ignorant. I've glanced at a few papers and read a bit of code but otherwise have vanishingly little knowledge about the type checker. I'm looking at this slightly easier example (which still replicates the failure), {{{#!hs {-# LANGUAGE PolyKinds #-} module Other where data Other (f :: k -> *) (a :: k) = Other (f a) }}} {{{#!hs {-# LANGUAGE DataKinds #-} module Main where import Data.Typeable import Other main :: IO () main = let a = typeOf (undefined :: Proxy 'Other) in return () }}} As before enabling `PolyKinds` in `Main` results in the expected insoluble `Typeable` error. `-ddump-tc-trace -fprint-explicit-kinds` produces the following suspicious output, {{{ decideKindGeneralisationPlan type: (Proxy k1_aJt[tau:5] ('Other k_aJB[tau:5] f_aJC[tau:5] a_aJD[tau:5] |> Other k_aJB[tau:5] f_aJC[tau:5] a_aJD[tau:5]>_N) |> <*>_N) ftvs: [k1_aJt[tau:5], f_aJC[tau:5], a_aJD[tau:5], k_aJB[tau:5]] should gen? True writeMetaTyVar k_aJB[tau:5] :: * := * writeMetaTyVar f_aJC[tau:5] :: k_aJB[tau:5] -> * := * writeMetaTyVar a_aJD[tau:5] :: k_aJB[tau:5] := * }}} If I'm interpreting this correctly `f` (which is of kind `k -> *`) is being instantiated as `*`. I'm going to eat some food; more later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 20:33:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 20:33:52 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.736034f6ee9cb6f5d78440bbbacc017e@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): > So the main question would be: Does the compiler consider unfoldings when determining whether a value is unused and thus can be replaced by `absentError`? I'm very impressed. You've waded though the swamp and indeed I think you have nailed a culprit. Whether it is ''the'' culprit in the original program I don't know, but this does look wrong. Just to lay it out, we have {{{ f x = let arr2 = ... let getIt :: Int -> Int [Unf = { Src=InlineStable, Tmpl=..arr2... }] getIt n = ...(no arr2)... in ... }}} So `arr2` is not used in `getIt`'s RHS (presumably because `arr2` has already been inlined into it, but it ''is'' used in `getIt`'s ''unfolding''. Moreover, it's a "stable" unfolding, meaning that it stays unaffected by transformations in `getIt`'s RHS. So the following sequence could happen * Strictness analysis thinks that `arr2` is unused * Worker-wrapper replaces its binding with `arr2 = absentError "blah"` * `getIt` is inlined at some call site, and lo! `arr2` is resurrected. Hmm. Now you have exposed this so well, it's clear that the demand analyser should take account of the free vars of the unfolding, at least so far as absence analysis is concerned. I'll look at how to do that. Most helpful. Please apply your forensic powers to other bugs :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 20:58:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 20:58:59 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.616eb8bab2483aadee83042305064e8f@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Easier example is good (comment:11). Hint: always debug a compiler built with `-DDEBUG`. My build shows {{{ decideKindGeneralisationPlan type: (Proxy k1_aCf[tau:5] ('Other k_aCn[tau:5] f_aCo[tau:5] a_aCp[tau:5] |> Other k_aCn[tau:5] f_aCo[tau:5] a_aCp[tau:5]>_N) |> <*>_N) ftvs: [k1_aCf[tau:5], f_aCo[tau:5], a_aCp[tau:5], k_aCn[tau:5]] should gen? True writeMetaTyVar k_aCn[tau:5] := * writeMetaTyVar f_aCo[tau:5] := * WARNING: file compiler\typecheck\TcMType.hs, line 553 Ill-kinded update to meta tyvar f_aCo[tau:5] :: k_aCn[tau:5] -> * * -> * := * :: * * writeMetaTyVar a_aCp[tau:5] := * quantifyTyVars globals: [] nondep: [] dep: [k_aCn[tau:5], f_aCo[tau:5], a_aCp[tau:5]] dep2: [] quant_vars: [] }}} Note the `WARNING`. The bug is this code in `quantifyTyVars`: {{{ -- In the non-PolyKinds case, default the kind variables -- to *, and zonk the tyvars as usual. Notice that this -- may make quantifyTyVars return a shorter list -- than it was passed, but that's ok ; poly_kinds <- xoptM LangExt.PolyKinds ; dep_vars2 <- if poly_kinds then return dep_kvs else do { let (meta_kvs, skolem_kvs) = partition is_meta dep_kvs is_meta kv = isTcTyVar kv && isMetaTyVar kv ; mapM_ defaultKindVar meta_kvs ; return skolem_kvs } -- should be empty }}} But in this case the variables we are quantifying over (I hardly know whether to call them type or kind variables now) are: {{{ k_aCn :: * f_aCo :: k_aCn -> * a_aCp :: k_aCn }}} These appear in the user-written type signature which elaborates to: {{{ Proxy ... (Other k_aCn f_aCo a_aCp) }}} It's clearly NOT RIGHT in the non-poly-kind case to default the "kind" variables to `*`. I guess we have to use `Any` in the same way that we do for types. Can't do more tonight. Richard how are you set? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 21:00:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 21:00:07 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.88f333d9f455b9b3a3d66bf7c69b3928@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Before I forget there is a bug in `decideKindGeneralisationPlan`, which is taking the free vars of an ''unzonked'' type. But I don't understand that function really. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 22:32:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 22:32:11 -0000 Subject: [GHC] #11502: Scrutinize use of 'long' in rts/ In-Reply-To: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> References: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> Message-ID: <060.676fec9d36753129ab0b8366cb0bb414@haskell.org> #11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: MarcelineVQ Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | 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 MarcelineVQ): * owner: => MarcelineVQ Comment: Is this an appropriate time to change int as well or is it enough to rely on the c-standard minimum int size to keep int usage safe? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 22:22:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 22:22:00 -0000 Subject: [GHC] #11502: Scrutinize use of 'long' in rts/ Message-ID: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> #11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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 commit 53055bb5023e8cc145ad8a9cd36ac56cee4695b0 (#5656), several uses of `int` in the rts were replaced by `long`, to avoid potential overflows for some calculations. On Windows though, `int` and `long` have the same size (4 bytes). Carefully go through all uses of `long` in `rts/`, and replace by one of the types from `includes/stg/Types.h`: * `long` -> `StgInt` or `StgInt64` * `unsigned long` -> `StgWord` or `StgWord64` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 27 22:57:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jan 2016 22:57:08 -0000 Subject: [GHC] #11502: Scrutinize use of 'long' in rts/ In-Reply-To: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> References: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> Message-ID: <060.b0d69c7549139034e445dc55a065b192@haskell.org> #11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: MarcelineVQ Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Using `int` is often fine, and sometimes unavoidable since lots of standard C library functions accept or return `int`. There may well be some cases where `int` is used wrongly, but there will be far more correct uses. I can't think of any legitimate use for `long` in the RTS, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 02:33:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 02:33:34 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.e63e11ceaeb59a25d4bf98ac905fdc14@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yech. First off, let's rename the data constructor and type constructor differently. I got quite confused about that! {{{ data Ty (f :: k -> *) (a :: k) = Con (f a) }}} This produces {{{ Ty :: forall k. (k -> *) -> k -> * Con :: forall k (f :: k -> *) (a :: k). (f a) -> Ty k f a }}} The question is: how should we interpret `Proxy 'Con` with `-XNoPolyKinds`? The old rule for `-XNoPolyKinds` was "set all kind variables to `*`", which is still what `quantifyTyVars` is doing. This used to make sense, because all kind variables used to have sort `BOX`, never something like `BOX -> BOX`. But those halcyon days are now gone. I suppose it would be reasonable to set all kind variables of kind `*` to be `*`, and use `Any` for the others. We don't want to just use `Any` all the time, because that wouldn't be backwards compatible and defaulting to `*` is quite sensible. The other reasonable way forward is to issue an error at `Proxy 'Con` without having more direction. For example, the user could say `Proxy ('Con :: Maybe Bool -> Ty * Maybe Bool)` to get the right instantiation. I actually prefer the "issue an error" option. The user could use a kind signature, but more likely should just enable `-XPolyKinds`. Using a promoted data constructor taken from a polykinded datatype without `-XPolyKinds` is asking for trouble. I'm happy to put this change in when I get to rounding up these tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 02:51:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 02:51:01 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.b46a1a459daeb7423e90a53c726bbb0f@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm very confused. Why would we error in the case of calling `print (typeOf (Proxy :: Proxy 'Comp))` whenever `-XNoPolyKinds` is enabled, whereas something like `print (typeOf (Proxy :: Proxy 'Proxy))` is OK? The latter currently yields `"Proxy (Proxy * *) 'Proxy"` when `-XNoPolyKinds` is on (or is this a bug?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 03:18:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 03:18:55 -0000 Subject: [GHC] #11502: Scrutinize use of 'long' in rts/ In-Reply-To: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> References: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> Message-ID: <060.374a731753c4c82f14883f32af837c24@haskell.org> #11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: MarcelineVQ Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | -------------------------------------+------------------------------------- Comment (by thomie): See also https://matt.sh/howto-c and https://github.com/Keith-S-Thompson /how-to-c-response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 03:37:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 03:37:17 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.3bd1b3dc37ea4ea30017cfd6d5c20086@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): `Proxy :: Proxy 'Proxy` should also be an error in my "issue an error" option. It's a use of a promoted data constructor of a datatype whose type parameters are not all `*`. To be honest, `-XNoPolyKinds` always confuses me now. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 03:55:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 03:55:58 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) Message-ID: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeFamilies, UndecidableInstances #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module Bug where import GHC.TypeLits import GHC.Exts ( Constraint ) type family NotInt a where NotInt Int = TypeError (Text "That's Int, silly.") NotInt _ = (() :: Constraint) data T a where MkT1 :: a -> T a MkT2 :: NotInt a => T a foo :: T Int -> Int foo (MkT1 x) = x }}} I get {{{ Bug.hs:19:1: warning: Pattern match(es) are non-exhaustive In an equation for ?foo?: Patterns not matched: MkT2 }}} But I shouldn't. Even worse, perhaps, GHC accepts my pattern-match against `MkT2` if I add it. If I change the `TypeError` to `False ~ True`, I get the correct behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 06:03:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 06:03:18 -0000 Subject: [GHC] #11504: Can't install haskell-platform in OpenBSD Message-ID: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> #11504: Can't install haskell-platform in OpenBSD -------------------------------------+------------------------------------- Reporter: Achifaifa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.3 system | Keywords: | Operating System: OpenBSD Architecture: x86 | Type of failure: Installing GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to install the haskell platform in openbsd. This is the output I get Can't install freeglut-2.8.0 because of libraries |library GL.13.0 not found | not found anywhere |library X11.15.1 not found | not found anywhere |library Xdamage.3.1 not found | not found anywhere |library Xext.12.0 not found | not found anywhere |library Xfixes.5.1 not found | not found anywhere |library Xi.11.1 not found | not found anywhere |library Xrandr.6.1 not found | not found anywhere |library Xrender.5.0 not found | not found anywhere |library Xxf86vm.5.0 not found | not found anywhere |library drm.3.1 not found | not found anywhere |library xcb.2.4 not found | not found anywhere Can't install hs-GLUT-2.1.2.1p11: can't resolve freeglut-2.8.0 Can't install haskell-platform-2012.4.0.0p0: can't resolve hs- GLUT-2.1.2.1p11 I'm installing it on a laptop without a desktop environment or X server, so I'm not sure if the problem is that I don't have a X/GL installation or if the installer can't locate some packages in the source. I'm a total newbie to both OpenBSD and Haskell, so I know nothing that could help with this. Let me know if you need any extra information about the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 06:04:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 06:04:19 -0000 Subject: [GHC] #11504: Can't install haskell-platform in OpenBSD In-Reply-To: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> References: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> Message-ID: <063.4a1732ca0ab6f5f0b8b7dc86addffbba@haskell.org> #11504: Can't install haskell-platform in OpenBSD ------------------------------------------+------------------------------ Reporter: Achifaifa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Description changed by Achifaifa: @@ -4,1 +4,1 @@ - Can't install freeglut-2.8.0 because of libraries + {{{Can't install freeglut-2.8.0 because of libraries @@ -30,1 +30,1 @@ - + }}} New description: I'm trying to install the haskell platform in openbsd. This is the output I get {{{Can't install freeglut-2.8.0 because of libraries |library GL.13.0 not found | not found anywhere |library X11.15.1 not found | not found anywhere |library Xdamage.3.1 not found | not found anywhere |library Xext.12.0 not found | not found anywhere |library Xfixes.5.1 not found | not found anywhere |library Xi.11.1 not found | not found anywhere |library Xrandr.6.1 not found | not found anywhere |library Xrender.5.0 not found | not found anywhere |library Xxf86vm.5.0 not found | not found anywhere |library drm.3.1 not found | not found anywhere |library xcb.2.4 not found | not found anywhere Can't install hs-GLUT-2.1.2.1p11: can't resolve freeglut-2.8.0 Can't install haskell-platform-2012.4.0.0p0: can't resolve hs- GLUT-2.1.2.1p11 }}} I'm installing it on a laptop without a desktop environment or X server, so I'm not sure if the problem is that I don't have a X/GL installation or if the installer can't locate some packages in the source. I'm a total newbie to both OpenBSD and Haskell, so I know nothing that could help with this. Let me know if you need any extra information about the issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 06:04:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 06:04:50 -0000 Subject: [GHC] #11504: Can't install haskell-platform in OpenBSD In-Reply-To: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> References: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> Message-ID: <063.5f4be52c4b2f2b2c689357552a3e32de@haskell.org> #11504: Can't install haskell-platform in OpenBSD ------------------------------------------+------------------------------ Reporter: Achifaifa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Description changed by Achifaifa: @@ -4,1 +4,1 @@ - {{{Can't install freeglut-2.8.0 because of libraries + {{{ Can't install freeglut-2.8.0 because of libraries @@ -29,2 +29,1 @@ - GLUT-2.1.2.1p11 - }}} + GLUT-2.1.2.1p11 }}} New description: I'm trying to install the haskell platform in openbsd. This is the output I get {{{ Can't install freeglut-2.8.0 because of libraries |library GL.13.0 not found | not found anywhere |library X11.15.1 not found | not found anywhere |library Xdamage.3.1 not found | not found anywhere |library Xext.12.0 not found | not found anywhere |library Xfixes.5.1 not found | not found anywhere |library Xi.11.1 not found | not found anywhere |library Xrandr.6.1 not found | not found anywhere |library Xrender.5.0 not found | not found anywhere |library Xxf86vm.5.0 not found | not found anywhere |library drm.3.1 not found | not found anywhere |library xcb.2.4 not found | not found anywhere Can't install hs-GLUT-2.1.2.1p11: can't resolve freeglut-2.8.0 Can't install haskell-platform-2012.4.0.0p0: can't resolve hs- GLUT-2.1.2.1p11 }}} I'm installing it on a laptop without a desktop environment or X server, so I'm not sure if the problem is that I don't have a X/GL installation or if the installer can't locate some packages in the source. I'm a total newbie to both OpenBSD and Haskell, so I know nothing that could help with this. Let me know if you need any extra information about the issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 06:19:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 06:19:01 -0000 Subject: [GHC] #11504: Can't install haskell-platform in OpenBSD In-Reply-To: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> References: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> Message-ID: <063.0e10cbf6e280d58b1424e6c40b6f0ad2@haskell.org> #11504: Can't install haskell-platform in OpenBSD ------------------------------------------+------------------------------ Reporter: Achifaifa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by thomie): Going by this email https://mail.haskell.org/pipermail/ghc- devs/2016-January/011140.html, try `pkg_add ghc` instead of `pkg_add haskell-platform`. That should be easier to get started with. In any case, this is not the haskell-platform bug tracker. If my suggestion didn't work, please ask on the haskell-cafe or glasgow-haskell- users mailinglist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 06:32:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 06:32:15 -0000 Subject: [GHC] #11504: Can't install haskell-platform in OpenBSD In-Reply-To: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> References: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> Message-ID: <063.88b9f9f0d72bfcebaa30a043675e24f7@haskell.org> #11504: Can't install haskell-platform in OpenBSD ------------------------------------------+------------------------------ Reporter: Achifaifa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by Achifaifa): Oh ok, thanks! To be honest I'm just interested in GHC and GHCI, I just got used to installing that in the other computer and decided to try that out in this one since I couldn't find the package for GHCI Apparently the haskell-platform install did *something* tho, since launching GHCI gives an error and tells me to open a bug here ;P {{{ GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.4.2 for i386-unknown-openbsd): interactiveUI:setBuffering2 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 Thu Jan 28 08:04:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 08:04:02 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.99ea297f9dcc3882b8e2dab9be20c5b8@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer 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 bollmann): * owner: => bollmann -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 09:02:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 09:02:47 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.490661644b2c0b88ca65b6cdb662f164@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I have also wondered how `NoPolyKinds` is supposed to behave. In fact, this is something that could probably use more explanation in the users guide. We discuss the behavior of `-XPolyKinds` in great depth but hardly mention how poly-kinded types should behave in modules with `-XNoPolyKinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 09:40:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 09:40:58 -0000 Subject: [GHC] #10707: -fth-dec-file outputs invalid case clauses In-Reply-To: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> References: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> Message-ID: <060.f0144b0d24924d7f57477033175d60ef@haskell.org> #10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10701 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): Replying to [comment:4 Fabian]: > Replying to [comment:3 rwbarton]: > > I'm not sure what you mean by "invalid case clauses", but it seems to me that the error is that > > {{{ > > case e of { ...alts... } foo > > }}} > > is not valid syntax for an application, it must be parenthesized like > > {{{ > > (case e of { ...alts... }) foo > > }}} > > A problem with the case expression itself in its context, not the case clauses. > > I wasn't sure exactly what was wrong with the output According to Fabian's specified AST (see the attached Test.hs), the problem rather seems to be missing parentheses around the lambda abstraction as well as missing semi-colons to separate the cases. That is, instead of pretty-printing {{{ instance Data.Aeson.Types.Class.ToJSON Language.Haskell.TH.Syntax.Name where Data.Aeson.Types.Class.toJSON x = \ k_a94l v_a94m -> case k_a94l of { GHC.Base.Just "" -> GHC.Err.undefined GHC.Base.Nothing -> GHC.Err.undefined } (GHC.Base.Just "test") "test2" }}} the code should be pretty-printed as: {{{ instance Data.Aeson.Types.Class.ToJSON Language.Haskell.TH.Syntax.Name where Data.Aeson.Types.Class.toJSON x = (\ k_a94l v_a94m -> case k_a94l of { GHC.Base.Just "" -> GHC.Err.undefined; -- note the ';' here GHC.Base.Nothing -> GHC.Err.undefined }) -- note the parentheses (GHC.Base.Just "test") "test2" }}} That should be easy to fix. I'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 09:41:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 09:41:13 -0000 Subject: [GHC] #10707: -fth-dec-file outputs invalid case clauses In-Reply-To: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> References: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> Message-ID: <060.b8c5e88dff0c7096483979bff2c67f1f@haskell.org> #10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10701 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * owner: => bollmann -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 11:10:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 11:10:47 -0000 Subject: [GHC] #10707: -fth-dec-file outputs invalid case clauses In-Reply-To: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> References: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> Message-ID: <060.bd1577a455d51abcb4224484e266dd12@haskell.org> #10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10701 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): Upon a first investigation, it seems that the pretty printer in `Language.Haskell.TH.Ppr` functions correctly (at least concerning the parentheses around the lambda abstraction). It hence seems as if the pretty printer that is actually called when dumping the splice via -dth-dec-file is not `Language.Haskell.TH.Ppr.pprint`? I will investigate this further... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 11:17:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 11:17:16 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.b06d85c5b60c35faab18d2496e8f9d57@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: bgamari => goldfire Comment: > I suppose it would be reasonable to set all kind variables of kind * to be *, and use Any for the others. We don't want to just use Any all the time, because that wouldn't be backwards compatible and defaulting to * is quite sensible. The other reasonable way forward is to issue an error at `Proxy 'Con` without having more direction I think I favour: * Default kind vars of kind `*` to `*` * Don't default others; instead error. But note that if we have `{k1:k2, k2:*}` then defaulting `k2` to `*` might mean we could then default `k1`. We do need to do deafulting somehow because even without `PolyKinds` consider {{{ data T f a = MkT (f a) }}} We get `{f :: k -> *, a :: k}` and we can't reject the program. Anyway, Richard, thanks for saying you'll get to it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 11:47:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 11:47:40 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.6594c2c2cad19f7a14255495fb8a8ae1@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"63700a193557ed63a1da18a6a059cb7ec5596796/ghc" 63700a19/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="63700a193557ed63a1da18a6a059cb7ec5596796" Use the in_scope set in lint_app This makes the call to `substTy` satisfy the invariant from Note [The substitution invariant] in TyCoRep. Test Plan: ./validate --slow Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1861 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 12:35:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 12:35:38 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.7a1016428d64e6a4f54a484c5dfa27af@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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 asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 12:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 12:54:17 -0000 Subject: [GHC] #10707: -fth-dec-file outputs invalid case clauses In-Reply-To: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> References: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> Message-ID: <060.24b008bd5eea08b2925ea48837f83f75@haskell.org> #10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10701 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That may well be true. If I recall, the other pretty-printer to look at is the one for `HsExpr`, in `hsSyn/HsExpr.hs`. It's quite possible that this ticket will be fixed when #10854 is complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 13:21:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 13:21:29 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) In-Reply-To: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> References: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> Message-ID: <062.8f04e5677f1bebaa1d2105c9873f6994@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings Comment: I think you are saying that {{{ type family NotInt a where NotInt Int = False ~ True NotInt _ = (() :: Constraint) }}} makes everything work. That's because the pattern-match warning infrastructure treats `False ~ True` as definitely insoluble. But apparently it doesn't treat `TypeErorr blah` as definitely insoluble. That's because when we solve `[G] NotInt Int`, we get `[G] TypeError ... ~ fsk, [G] fsk`, and neither is treated as insoluble. I'm sure this can be dealt with, but it'll need a little care. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 14:51:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 14:51:24 -0000 Subject: [GHC] #11505: Boot file problem Message-ID: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: -------------------------------------+------------------------------------- Here are two modules and a boot file. Compile by {{{ ghc -c Foo.hs-boot; ghc -c Bar.hs; ghc -c Foo.hs }}} and observe this error message {{{ Foo.hs:12:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: {-# UNPACK #-} !Int} Boot file: data Foo = Foo {x :: !Int} }}} But the definitions are not conflicting, they are identical. Foo.hs-boot: {{{ module Foo where data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Foo.hs: {{{ module Foo where import Bar data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} Removing the unbox pragma gives the even more perplexing: {{{ Foo.hs:3:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: !Int} Boot file: data Foo = Foo {x :: !Int} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 15:31:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 15:31:28 -0000 Subject: [GHC] #11505: Boot file problem In-Reply-To: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> References: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> Message-ID: <062.72ac8f52f7079cb56badb14a01aa98bf@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 jstolarek): I can confirm this error in GHC 7.10.3 but not in HEAD. Can someone verify whether it exists on ghc-8.0 branch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 16:05:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 16:05:57 -0000 Subject: [GHC] #11505: Boot file problem In-Reply-To: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> References: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> Message-ID: <062.c3d7d59a204c53c82256421da0cc9675@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 rwbarton): I can confirm that the error does not occur in 8.0. {{{ rwbarton at morphism:/tmp/boot$ ls Bar.hs Foo.hs Foo.hs-boot rwbarton at morphism:/tmp/boot$ GHC=~/ghc-8.0-install/bin/ghc rwbarton at morphism:/tmp/boot$ $GHC --version The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160123 rwbarton at morphism:/tmp/boot$ $GHC -c Foo.hs-boot; $GHC -c Bar.hs; $GHC -c Foo.hs rwbarton at morphism:/tmp/boot$ rm *.hi* *.o*; ls Bar.hs Foo.hs Foo.hs-boot rwbarton at morphism:/tmp/boot$ GHC=ghc-7.10.1 rwbarton at morphism:/tmp/boot$ $GHC --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 rwbarton at morphism:/tmp/boot$ $GHC -c Foo.hs-boot; $GHC -c Bar.hs; $GHC -c Foo.hs Foo.hs:4:2: Type constructor ?Foo? has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: !Int} Boot file: data Foo = Foo {x :: !Int} The constructors do not match: The strictness annotations for ?Foo? differ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 16:08:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 16:08:37 -0000 Subject: [GHC] #11505: Boot file problem In-Reply-To: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> References: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> Message-ID: <062.2f42326ffbb3cc6157f69edae73264da@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 simonpj): But the message is a bit strange: it claims that the annotations differ, but then prints out the identical annotations... Something still looks wrong there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 16:11:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 16:11:55 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.e30a92e123581a92dbd3efb7a0a6f9ce@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | 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 goldfire): We have a Levity wiki page: NoSubKinds It needs an update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 16:12:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 16:12:36 -0000 Subject: [GHC] #11505: Boot file problem In-Reply-To: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> References: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> Message-ID: <062.c094ad817ab2dd75f2bdb888d0563ea2@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 rwbarton): My last comment was possibly confusing. The error with the identical declarations is from 7.10, not 8.0. I've edited it to try to make it more clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 16:31:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 16:31:28 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.765abf047f40c07c3d881f68d8656ac5@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `exceptionsrun001` still fails for me in the `hpc` way. Could it be OS- dependent? {{{ rwbarton at morphism:~/ghc-newest/testsuite/tests$ make TEST=exceptionsrun001 WAY=hpc [...] =====> exceptionsrun001(hpc) 1 of 1 [0, 0, 0] cd ../../libraries/base/tests && "/home/rwbarton/ghc-newest/inplace/test spaces/ghc-stage2" -o exceptionsrun001 exceptionsrun001.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -O -fhpc -hpcdir .hpc.exceptionsrun001 > exceptionsrun001.comp.stderr 2>&1 cd ../../libraries/base/tests && ./exceptionsrun001 exceptionsrun001.run.stdout 2> exceptionsrun001.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: user exception caught error call caught no method error Stderr: exceptionsrun001: exceptionsrun001.hs:38:1-13: Non-exhaustive patterns in function test1 *** unexpected failure for exceptionsrun001(hpc) Unexpected results from: TEST="exceptionsrun001" OVERALL SUMMARY for test run started at Thu Jan 28 11:30:04 2016 EST 0:00:01 spent to go through 1 total tests, which gave rise to 10 test cases, of which 9 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: ../../libraries/base/tests exceptionsrun001 [bad exit code] (hpc) }}} I will try to look into why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 17:31:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 17:31:17 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.9241526bbf2141abd1e893b023a56e9f@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well the test is wrong in the same way as the others. {{{ patMatchTest = catch (case test1 [1..10] of () -> return ()) (...) }}} where `test1 [1..10]` results in a pattern match failure. Maybe the best question is why the test ''doesn't'' fail with way optasm. After all why not evaluate `case test1 [1..10] of () -> return ()` first, if `catch` is strict in that argument. That argument becomes (up to a coercion) {{{ a_s2uX :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 290 30}] a_s2uX = \ (eta_B1 [OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Base.build @ Integer (\ (@ b_a2uz) (c_a2uA [OS=OneShot] :: Integer -> b_a2uz -> b_a2uz) (n_a2uB [OS=OneShot] :: b_a2uz) -> GHC.Enum.enumDeltaToInteger1FB @ b_a2uz c_a2uA n_a2uB 1 10) of _ [Occ=Dead] { [] -> (# eta_B1, GHC.Tuple.() #); : ipv_s2hb ipv_s2hc -> case lvl_s2v4 of wild_00 { } } }}} Perhaps some of the `Value=True, ConLike=True, WorkFree=True, Expandable=True` flags are causing the value not to get evaluated eagerly. Is that what GHC should be doing? (The hpc version has all those flags set to `False`, maybe because of the ticks wrapping the expression, or because the coercion was not removed yet: the hpc version of this binding has type `IO ()` still.) Anyways, GHC's behavior is correct either way, but maybe there is something to learn here before fixing the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 17:48:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 17:48:50 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.545c76c416c05a20c93ca5d71946624e@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): slyfox helped me git-bisect the bug and it turns out that the faulty commit is ffc21506894c7887d3620423aaf86bc6113a1071. Commit message says: {{{ - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 17:49:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 17:49:49 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.66439f5c3180ac2ea21954918026593f@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): * Attachment "bisect.log" added. git-bisect log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 17:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 17:51:42 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.8ff1a9d4eb32d992120ebce93a4a549c@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 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 rwbarton): * status: infoneeded => new Comment: I don't know whether this will resolve the original issue, but I think we should implement slyfox's suggestion as described in comment:17 and comment:19. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 17:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 17:59:21 -0000 Subject: [GHC] #11486: info tables are no longer aligned In-Reply-To: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> References: <047.1b9911e5d26f5319adcd09fdcb8b94a9@haskell.org> Message-ID: <062.85e7133d1611702508c374b9b0bc573e@haskell.org> #11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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:D1847 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This had a small, but mostly beneficial effect on performance: https://perf.haskell.org/ghc/#revision/0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6 As expected, there is a code size cost, which has an indirect performance cost as well (since density of real code in the instruction cache is lower). Not exactly germane to this ticket, but perhaps it would be worth experimenting with half-word-aligned info tables? Many of the info table fields are half-word-sized anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 19:32:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 19:32:41 -0000 Subject: [GHC] #11506: uType_defer can defer too long Message-ID: <047.ae5cd8f98e9780fa8bd0e79c7e829136@haskell.org> #11506: uType_defer can defer too long -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Here is the test case: {{{ {-# LANGUAGE PolyKinds, ExistentialQuantification, ScopedTypeVariables, TypeFamilies, TypeInType #-} module Bug where import Data.Proxy import Data.Kind type family ProxyType where ProxyType = (Proxy :: Type -> Type) data T = forall a. MkT (ProxyType a) foo (MkT (_ :: Proxy a)) = const True (undefined :: a) }}} This should be accepted. But I get {{{ Bug.hs:13:53: error: ? Expected a type, but ?a? has kind ?k10? ? In an expression type signature: a In the second argument of ?const?, namely ?(undefined :: a)? In the expression: const True (undefined :: a) }}} Why should it be accepted? GHC can infer that the existential `a` in `MkT` has kind `Type`. (Indeed this works.) Then, we should unify the pattern signature `Proxy k1 a1` with `ProxyType a2`; the latter expands to `Proxy Type a2` and we get `k1 := Type` and `a1 := a2`, allowing `undefined :: a` to be accepted. Why doesn't it work? When checking the pattern type signature in `foo`, GHC then checks if `ProxyType a2` is a subtype of `Proxy k1 a1`. This check is deferred because of the type family. In a short while, GHC needs to know that `a` has kind `Type` to make sure that `undefined :: a` is well-typed. At this point, it doesn't know that `a` has kind `Type` (because the unification was deferred), and so an error is issued. I'm not sure how to resolve this. This is indeed a consequence of `TypeInType`, but it seems more to do with solver engineering than the new `TypeInType` stuff. And there is an easy workaround: just add a kind signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 20:01:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 20:01:06 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.80e2dd523c5846c9c8f9ca5f43de1b67@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 mpickering): So * Revert the relevant part of that commit * Add a test * Add a note explaining why it is parsed as a data constructor rather than a type constructor? Will that fix the problem? Does that sound like a reasonable plan? Do you want to take care of it skvardrik? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 20:38:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 20:38:00 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.7bbe5663985737803de35c46f38df939@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): `catch` is ''not'' strict in its argument. Its argument is a function; `catch` just guarantees to call that function. So yes `build (...)` is sure to be evaluated, but GHC doesn't aggressively evaluate things as early as possible. It just uses strictness info to avoid building thunks; and none are built here. So I think it's fine. Might be wroth fixing the test though. Thanks for the accurate diagnosis. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 20:46:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 20:46:46 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.578af51038a59e4c51b5f5d898d8fafe@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Well `(-.->)` isn't (lexically) a data constructor either, so I have no idea why it worked before the commit but not after. If we understand why it worked before, we'd have a better chance of not messing something else up. I see {{{ qcname :: { Located RdrName } -- Variable or type constructor : qvar { $1 } | oqtycon_no_varcon { $1 } -- see Note [Type constructors in export list] }}} so obviously look carefully at that `Note` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 21:10:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 21:10:05 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.66c57a887199907fd65eaae9cfcb22d1@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): I think `-.->` is lexically `@varsym` (and `VARSYM` parser) and `(-.->)` is parsed as `'(' VARSYM ')'`: {{{ ... qcname -> qvar -> '(' varsym ')' -> '(' varsym_no_minus ')' -> '(' VARSYM ')' }}} I don't know yet why it did work before commit ffc21506894c7887d3620423aaf86bc6113a1071, but I suspect the answer is hidden not in grammar, but in the way data constructors are (were?) "fixed" after parsing to become type constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 21:17:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 21:17:52 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.3695ae979dd7a4634e596cd73e7ee73f@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): Simply reverting the relevant part of grammar does not work (even if it did, the fix is spurious). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 21:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 21:26:15 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.8eb4796a7bf19a5f89a5fef0dabf7a4c@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 skvadrik): Replying to [comment:18 mpickering]: > Do you want to take care of it skvardrik? Yes, it will take me some time to make the right fix though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 21:47:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 21:47:21 -0000 Subject: [GHC] #11506: uType_defer can defer too long In-Reply-To: <047.ae5cd8f98e9780fa8bd0e79c7e829136@haskell.org> References: <047.ae5cd8f98e9780fa8bd0e79c7e829136@haskell.org> Message-ID: <062.c28f6bccd97af59d070a678ad9666011@haskell.org> #11506: uType_defer can defer too long -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): It's more than solver engineering. A pretty fundamental assumption is that a user-writen type signature (at least one without wildcards) specifies a ''fully-defined'' type. No unification variables; a fully defined type. Not necessarily closed; e.g. here the type sig for 'g' is fully defined although it mentions 'a': {{{ f :: forall a. blah f x = let g :: a -> a g x = x in ... }}} But pattern signatures threaten this happy story. They bring into scope a type variable as a name for a type that may not yet be fully defined, and certainly isn't here. Much simpler situations can do this too: {{{ f (x::a, b) = let g :: a -> a g = ... in ... }}} Here `a` will end up being the name of a unification variable. This hasn't caused trouble before, but now it is. If we switched off on- the-fly unification, and did everything in the solver, I bet a lot more instances would pop up. What's irritating is that the ability to name unification variables (or type variables with as-yet-unknown kinds) is not really sought. It's just hard to exclude. One possible solution would be to make pattern signatures do matching (not unification) with the "expected" type, and then insist that the scoped type variable matched a skolem. Another would be to treat type variables bound in this way more like wildards. If we have {{{ f :: _ -> Maybe _ or :: _ -> Int }}} then we use ''inference'' not checking, and simply use the signature as a "shape" against which the inferred type is matched. So a type signature with any wildcards is NOT treated as a fully defined type. Maybe a type signature with a free type variable bound by a pattern signature should be treated similarly. The machinery to do so is all there now. Uggle. I doubt I'll get to this quickly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 21:51:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 21:51:00 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.fc30244c799d938428be604ce4b155ca@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1864 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gmainland): * differential: Phab:D1858 => Phab:D1864 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 28 23:19:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jan 2016 23:19:03 -0000 Subject: [GHC] #11482: Turn -fdefer-typed-holes on by default In-Reply-To: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> References: <045.96a28492b441cc77271c9c1a54fa3253@haskell.org> Message-ID: <060.85f56192b6ad7446d6f5fa0a2ae59f25@haskell.org> #11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9497, #11481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Another option would be to turn `-fdefer-typed-holes` on by default in GHCi only. I'm not sure about this though. I general I prefer GHCi and GHC to behave the same as much possible. Their difference with regard to the MonomorphismRestriction is annoying enough already. > Cabal / stack use -fno-defer-typed-holes by default. Do you mean `cabal init` would add `ghc-options: -fno-defer-typed-holes` to the `*.cabal` file it creates? Or the default `.cabal/config` would get that entry? Or Cabal would always pass it to ghc? One workflow is to add library dependencies to a `.cabal` file, and then run `cabal repl`, which starts ghci. I like the suggestion of emitting a shorter warning for holes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 00:17:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 00:17:03 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.a31c30ac10ef1b1224e9ed7cba7b3a01@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Comment (by alfa07): Thank you Peter! I will try, not sure I will be able to make stack work with ghc-8 though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 00:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 00:23:46 -0000 Subject: [GHC] #11507: `GHC.Base.eqString`'s documentation is messed up Message-ID: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> #11507: `GHC.Base.eqString`'s documentation is messed up -------------------------------------+------------------------------------- Reporter: czipperz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Reads: {{{#!hs {-# RULES "eqString" (==) = eqString #-} -- eqString also has a BuiltInRule in PrelRules.lhs: -- eqString (unpackCString# (Lit s1)) (unpackCString# (Lit s2) = s1==s2 }}} The problem is that the string at `(unpackCString# (Lit s2) =` is unclosed (should be `(unpackCString# (Lit s2))`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 00:24:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 00:24:14 -0000 Subject: [GHC] #11507: `GHC.Base.eqString`'s documentation is messed up In-Reply-To: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> References: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> Message-ID: <062.50f019802b48d8d0103916d99f3d7035@haskell.org> #11507: `GHC.Base.eqString`'s documentation is messed up -------------------------------------+------------------------------------- Reporter: czipperz | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- @@ -12,0 +12,3 @@ + + Saw at + http://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Base.html New description: Reads: {{{#!hs {-# RULES "eqString" (==) = eqString #-} -- eqString also has a BuiltInRule in PrelRules.lhs: -- eqString (unpackCString# (Lit s1)) (unpackCString# (Lit s2) = s1==s2 }}} The problem is that the string at `(unpackCString# (Lit s2) =` is unclosed (should be `(unpackCString# (Lit s2))`). Saw at http://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Base.html -- Comment (by czipperz): http://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Base.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 00:59:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 00:59:06 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.8efaeca4138e17ab0d3513d66a4dde8e@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 04:27:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 04:27:21 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.c6185c559921783f70ab3682b9e31471@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"1b72534b99ea17012746ef97b4892a7c9c3450dd/ghc" 1b72534/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1b72534b99ea17012746ef97b4892a7c9c3450dd" Fixup test for #10728 It was failing for WAY=ghci. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 04:27:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 04:27:21 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.c195be205e1f635cf8f1fc14737efebf@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"61e4d6b10e06e820d976137b223b1f4f6dbed2a6/ghc" 61e4d6b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="61e4d6b10e06e820d976137b223b1f4f6dbed2a6" Mark dynamic-paper as expect_fail_for optasm and optllvm (#11330) It passes with `-O -fhpc` though, strange... (I didn't read the paper) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 04:46:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 04:46:17 -0000 Subject: [GHC] #11507: `GHC.Base.eqString`'s documentation is messed up In-Reply-To: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> References: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> Message-ID: <062.3c30e006b2c627e1fece152f78a61697@haskell.org> #11507: `GHC.Base.eqString`'s documentation is messed up -------------------------------------+------------------------------------- Reporter: czipperz | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"0dd663ba9111d78be116480e2f75bc272f3adc90/ghc" 0dd663ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0dd663ba9111d78be116480e2f75bc272f3adc90" Add closing parenthesis in comment for eqString (#11507) Spotted by czipperz }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 04:46:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 04:46:40 -0000 Subject: [GHC] #11507: `GHC.Base.eqString`'s documentation is messed up In-Reply-To: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> References: <047.c2940ee0b5a2df3543a5b49b008c867c@haskell.org> Message-ID: <062.9346afa9c39e0d0861d665bd0597cc77@haskell.org> #11507: `GHC.Base.eqString`'s documentation is messed up -------------------------------------+------------------------------------- Reporter: czipperz | Owner: 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: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 08:52:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 08:52:05 -0000 Subject: [GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) In-Reply-To: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> References: <045.051b0256ab9a07b148a027389e8de3e1@haskell.org> Message-ID: <060.1be8390221e69c3714841e69b0547926@haskell.org> #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/dynamic- | paper Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to be clear, the `expect_fail` is because of the issue in comment:2. The code says {{{ delta1 :: Dynamic -> Dynamic -- NB: this function behaves like a negative-recursive data type -- and hence leads compiler into an infinite inlining loop, -- and we get "simplifier ticks exhausted". -- See Section 7 of the paper "A reflection on types" delta1 dn = case fromDynamic dn of Just f -> f dn Nothing -> dn loop1 = delta1 (toDynamic delta1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 08:59:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 08:59:06 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan Message-ID: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: https://github.com/centromere | /ghc-bug-testcase | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you configure the test case like so: {{{ $ cabal configure --enable-tests -fbad }}} The QuickCheck application will hang when executed: {{{ $ ./dist/build/properties/properties --quickcheck-verbose --quickcheck- tests 10 10 9 8 7 6 5 4 3 2 1 10 testCase 1 a: }}} If you compile it without the 'bad' flag, it will execute successfully. The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 08:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 08:59:56 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.e4eb76f8927967bb6ae43c474987019d@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | https://github.com/centromere/ghc- | bug-testcase Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by orion): * Attachment "truss_output.txt" added. Truss output from bad application -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 09:00:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 09:00:24 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.80c94ef8b81031040c3d6d3f5669d7bc@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | https://github.com/centromere/ghc- | bug-testcase Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by orion: @@ -29,1 +29,3 @@ - The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. + The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. Attached + is the output from truss when run against the bad version of the + application. New description: If you configure the test case like so: {{{ $ cabal configure --enable-tests -fbad }}} The QuickCheck application will hang when executed: {{{ $ ./dist/build/properties/properties --quickcheck-verbose --quickcheck- tests 10 10 9 8 7 6 5 4 3 2 1 10 testCase 1 a: }}} If you compile it without the 'bad' flag, it will execute successfully. The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. Attached is the output from truss when run against the bad version of the application. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 11:11:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 11:11:44 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" Message-ID: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 {{{#!hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module Bug where import Data.Kind import Data.Typeable import GHC.StaticPtr {------------------------------------------------------------------------------- Standard Cloud-Haskell-like infrastructure See for a dicussion of 'SC'. -------------------------------------------------------------------------------} class Serializable a -- empty class, just for demonstration purposes instance Serializable a => Serializable [a] data Static :: * -> * where StaticPtr :: StaticPtr a -> Static a StaticApp :: Static (a -> b) -> Static a -> Static b staticApp :: StaticPtr (a -> b) -> Static a -> Static b staticApp = StaticApp . StaticPtr data Dict :: Constraint -> * where Dict :: c => Dict c class c => SC c where dict :: Static (Dict c) instance (Typeable a, SC (Serializable a)) => SC (Serializable [a]) where dict = aux `staticApp` dict where aux :: StaticPtr (Dict (Serializable a) -> Dict (Serializable [a])) aux = static (\Dict -> Dict) {------------------------------------------------------------------------------- Demonstrate the bug -------------------------------------------------------------------------------} newtype MyList a = MyList [a] deriving instance (Typeable a, SC (Serializable a)) => SC (Serializable (MyList a)) }}} This gives the following type error: {{{ Bug1.hs:40:1: error: ? Can't make a derived instance of ?SC (Serializable (MyList a))?: The data constructors of ?Serializable? are not all in scope so you cannot derive an instance for it ? In the stand-alone deriving instance for ?SC (Serializable a) => SC (Serializable (MyList a))? }}} This of course doesn't make much sense: `Serializable` is a type class, not a datatype, and doesn't have data constructors. I wasn't sure if this deriving clause was going to work at all, or whether I would expect it to. Since `MyList` is a newtype wrapper around `[a]`, and we have the requisite instance {{{#!hs instance (Typeable a, SC (Serializable a)) => SC (Serializable [a]) }}} I was kind of hoping that `GeneralizedNewtypeDeriving` would work its magic. However, even if it cannot, the error message should probably change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 14:23:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 14:23:08 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.e4a617f2755178cced9927c5f0d0ca0a@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | https://github.com/centromere/ghc- | bug-testcase Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pgj): * os: FreeBSD => Unknown/Multiple Comment: Based on the description in the ticket, I believe it is not platform- specific, so I am updating the respective field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 14:47:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 14:47:54 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.923a16d06c08d35d05c064308deab1ff@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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! Interesting. The error message embodies the assumption that in {{{ instance .. => C (T a b c) }}} that `T` is an algebraic data type; but here is is a class. So a question arises: * Does GND work for classes? Well, does this work? {{{ instance (Typeable a, SC (Serializable a)) => SC (Serializable (MyList a)) where dict = coerce (dict :: Static (Dict (Serializable [a]))) }}} If we got past the test, I think that's what we'd generate. I suspect you'll get a similar error from the `corece`, but try it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 15:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 15:13:26 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc Message-ID: <050.e08b70941207067cd22a7124ead2f765@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- With GHC 7.10.2 the Show instance was still present and for me it's somewhat inconvenient not to have one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 15:32:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 15:32:21 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective Message-ID: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A question came up during discussion at University of Wroc?aw: {{{#!hs type family F a = r | r -> a where F a = [F a] }}} Should this pass the injectivity check? Currently it does but I don't think this is correct. After all `F Bool` and `F Char` both reduce to the same infinite type `[[[...]]]`, which by definition of injectivity gives us `Char ~ Bool`. Is this dangerous in practice? It can cause reduction stack overflow (or an infinite loop if you disable that check) but I don't think this can be used to construct unsafe coerce. We'd have to unify two infinite types, which does not seem possible. This is not an implementation problem - this stays faithful to theory developed in injective type families paper. If others agree that this is indeed incorrect then I think the right solution here would be to drop equation (7) from our algorithm in the paper. For generalized injectivity we planned drop that equation anyway. Here's another reason for doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 17:07:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 17:07:58 -0000 Subject: [GHC] #10707: -fth-dec-file outputs invalid case clauses In-Reply-To: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> References: <045.fdc065ae6f0ee29227ba606c71d9b30e@haskell.org> Message-ID: <060.81432aff6f99deb98092385ca63e7d2d@haskell.org> #10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10701 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): @goldfire: good reference, thanks! Indeed, applying a lambda abstraction was not correctly parenthesized when converting from TH `Exp`s to `HsExpr`s in `hsSyn/Convert.hs`. However, this has been fixed in #10603. Thus, it would only remain to put semicolons between the different alternatives of the `HsCase` expression in order to make pretty printed code parse again (wrt this particular ticket). It seems to me that adding these ';' could be done by adjusting `pprMatches` in `hsSyn/HsExpr`. But I'm not sure if this rather ad-hoc approach is right, more so since I suspect that there might be other Haskell constructs where the pretty- printer does not print ';' between multiple case alternatives. Any ideas on how to proceed best with this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 17:31:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 17:31:14 -0000 Subject: [GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be. Message-ID: <047.7a36187500c6876edf467692a28ef5b3@haskell.org> #11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails: {{{#!hs {-# LANGUAGE PolyKinds, TypeApplications, ScopedTypeVariables #-} module Bug where import Data.Proxy class C a where foo :: Proxy a bar :: forall a. C a => Proxy a bar = foo @a }}} But it really should work, because the invisible kind variable to class `C` should not be available for type application. On the last line, `foo @_ @a` works, when you explicitly instantiate the kind variable. Also, saying `:t foo` in GHCi shows the specified kind variable. Will fix. At some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 18:03:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 18:03:13 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.64dbfee2c90d3451f825c9cb405a474b@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1866 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 18:07:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 18:07:37 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified Message-ID: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now, there's not a clear specification of when GADT data constructor parameters should be specified, and what order they appear in. For example: {{{ data G a where MkG :: b -> a -> G a }}} To my eye, we should get `MkG :: forall b a. b -> a -> G a`. But GHC now gives `MkG :: a {b}. b -> a -> G a`. At least two things are going on here: 1. GHC puts all universals before existentials. 2. There is an outright bug in `mkDataCon` that makes existentials act as inferred variables, but only for the representation type, not the wrapper type. You can witness (2) by noting that the `b` magically becomes specified if you put a strictness annotation (thereby necessitating the construction of a wrapper) anywhere. I'm not sure what to do about (1), from a design standpoint. Here are some thoughts. A. Having universals always come before existentials is convenient in pattern matching. When we have type application in patterns, you'll want to match only on existentials, never universals. So keeping the existentials together makes some sense. The universals will be omitted from the match entirely. B. FC absolutely requires that the universals come first. So if we allow the user to reorder the variables, that will necessitate creating a wrapper. Are there performance implications? That would be sad. C. We could tread a middle path, where if the user writes a `forall`, they get the order requested. Otherwise, they get universals first (whose order is taken from the ordering in the `data` declaration head) followed by existentials (whose order is taken from left-to-right first occurrence in the constructor type signature). But this is different than for functions, where we always use left-to-right ordering, even when lacking a `forall`. I tend to think that we should always just do what the user asks, but I'm worried about performance implications of this decision. It will make wrappers necessary for existential constructors that otherwise don't need them. Note that this whole debate is about only GADT constructors, not Haskell98 ones. Haskell98 constructors will always have universals before existentials, because that's quite obvious from the way they're declared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 18:30:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 18:30:08 -0000 Subject: [GHC] #11514: Impredicativity is still sneaking in Message-ID: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> #11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 erroneously accepted: {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo :: forall a. (Show a => a -> a) -> () foo = undefined }}} `undefined` is being instantiated at `(Show a => a -> a) -> ()`, which requires impredicativity. GHC does the right thing (reject!) if we try to instantiate with a type involving proper foralls. I imagine this is a simple missing check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 18:54:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 18:54:48 -0000 Subject: [GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families Message-ID: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> #11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE ConstraintKinds, TypeFamilies #-} module Bug where type family ShowSyn a where ShowSyn a = Show a foo :: (ShowSyn a, _) => a -> String foo x = show x }}} I get {{{ Bug.hs:7:20: error: Found constraint wildcard ?_? standing for ?Show a? To use the inferred type, enable PartialTypeSignatures In the type signature: foo :: (ShowSyn a, _) => a -> String }}} But if I fill in my wildcard with `Show a`, I'll rightly get a redundant constraint. Just a vanilla type synonym works there, but the type family causes trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 20:00:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 20:00:11 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.2d4a89a575e9d31610b3931a9240d264@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 8.1 => 7.0.1 * differential: => Phab:D1868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 20:08:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 20:08:56 -0000 Subject: [GHC] #11005: GHC's build system can't deal with ghc install path with multiple spaces in it In-Reply-To: <045.0d928970c6a7b251f3729849ff0cfe3e@haskell.org> References: <045.0d928970c6a7b251f3729849ff0cfe3e@haskell.org> Message-ID: <060.0982521096b6426f25bead69d040b99f@haskell.org> #11005: GHC's build system can't deal with ghc install path with multiple spaces in it -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Build System | Version: 7.11 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 thomie): If I understand correctly, to reproduce the bug: * Install GHC into a directory with spaces. * Use that GHC as a bootstrap compiler, to build GHC again. The first step already succeeds, and the installed compiler should generally be usable, because `validate` uses it to run the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 20:19:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 20:19:12 -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.8a7bc30d0bdfb24d2ff9c8938f9f8f56@haskell.org> #989: Build GHC on Windows using Microsoft toolchain ------------------------------------+--------------------------- Reporter: simonmar | Owner: 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: | ------------------------------------+--------------------------- Changes (by thomie): * component: Build System => Compiler Comment: This reaches far beyond just the build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 20:33:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 20:33:06 -0000 Subject: [GHC] #284: RPM doesn't support --prefix In-Reply-To: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> References: <046.1144a6291b544d9e99e352d8d1860ffd@haskell.org> Message-ID: <061.6e03358e928dcc68157c0ba64209951e@haskell.org> #284: RPM doesn't support --prefix -------------------------------------+------------------------------------- Reporter: skaller | Owner: juhp Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Build System | Version: None Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: None => invalid Comment: I'm closing this, since we don't ship RPMs anymore: commit 22690c9900068b121863dc359b8c7699b453e70d: {{{ Author: Ian Lynagh Date: Sun Jun 9 18:56:58 2013 +0100 Remove ghc.spec It doesn't look like it would work now, and doesn't really belong in the GHC tree anyway. }}} ydewit: please open a new ticket if you want to investigate relocatable installs on non-windows platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 20:47:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 20:47:49 -0000 Subject: [GHC] #10310: MakingReleases outdated or build system problems In-Reply-To: <042.d2b90211853dfb2585ae68e348e1e1af@haskell.org> References: <042.d2b90211853dfb2585ae68e348e1e1af@haskell.org> Message-ID: <057.239f41f65dfbdf11d6cc9d9f0705d18c@haskell.org> #10310: MakingReleases outdated or build system problems -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Turns out both issues are fixed already: * The [wiki:MakingReleases] page now mentions to run `./mk/get- win32-tarballs.sh download all` first. * When `mk/build.mk` says to build the documentation, but configure figured out that the right tools aren't available, then the build will error out with a nice message (#10157). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 20:56:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 20:56:25 -0000 Subject: [GHC] #11082: Tweak workflow around overlong lines In-Reply-To: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> References: <047.824d6cc980bf9acce584f8e65211c327@haskell.org> Message-ID: <062.9879ec249d688df67bbec8ec7b52e12d@haskell.org> #11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.10.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 thomie): * status: new => closed * resolution: => wontfix Comment: This is not a build system issue. Please take your quibbles to [https://phabricator.haskell.org/project/view/2/ Phabricator], where Austin can see them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 21:04:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 21:04:32 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.7e8ffcac39c457d1fdee8bf8e7ddbbab@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: fixed | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11480, | polykinds/T11480a Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * Attachment "Categories.hs" added. full test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 21:06:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 21:06:54 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.36ef9041bb8162966716642b32ab00fb@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: fixed | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11480, | polykinds/T11480a Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I've attached the full source file that I was trying to compile when I found this issue. With the above patches merged in, it compiles clean, but it may supply you with a longer worked example for testing that uses a lot of advanced techniques together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 22:41:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 22:41:44 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.49b8c89d49a55cc911851b3e2a516bc2@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+------------------------------ Reporter: kgardas | Owner: thomie Type: bug | Status: new Priority: highest | Milestone: Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by thomie): * owner: => thomie Comment: This commit caused it: https://phabricator.haskell.org/rGHC351dea4a7c07#31880. Instead of reverting that commit, I plan to fix bootstrapping with HEAD by enabling `MIN_VERSION` support without `-hide-all-packages` (see ticket:10970#comment:7). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 23:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 23:48:42 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.104043492ca46a3d756473e5dc894f37@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Changes (by thomie): * differential: Phab:D1349 => Phab:D1349, Phab:D1869 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 29 23:51:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jan 2016 23:51:56 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.f12e61fde985edaae517c9f392b45f86@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+---------------------------------- Reporter: kgardas | Owner: thomie Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1869 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by thomie): * cc: ekmett (removed) * component: Core Libraries => Compiler * differential: => Phab:D1869 * os: Solaris => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 06:04:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 06:04:22 -0000 Subject: [GHC] #11516: Panic, "falls into a hole" Message-ID: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> #11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs {-# language PolyKinds #-} {-# language FlexibleContexts #-} {-# language ConstraintKinds #-} {-# language FlexibleInstances #-} {-# language FunctionalDependencies #-} import GHC.Types (Constraint) class R?ki (p :: i -> i -> *) class (R?ki p) => Varpi p q f | f -> p q instance Varpi () () f => Varpi (->) (->) (Either f) where }}} causes {{{ % ghci -ignore-dot-ghci /tmp/testing.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/testing.hs, interpreted ) /tmp/testing.hs:11:10: error:ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): fvProv falls into a hole {a13R} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 12:00:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 12:00:46 -0000 Subject: [GHC] #11517: ghc -haddock fails to parse doc comments in closed type families Message-ID: <045.6e534193d5df30ad266d62db0469354a@haskell.org> #11517: ghc -haddock fails to parse doc comments in closed type families -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: Haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC with -haddock fails to parse the following program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Closed a where -- |This comment fails to parse Closed Int = Bool }}} {{{ ghc -haddock Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: parse error on input ?-- |This comment fails to parse? }}} (tested with 7.10.3 and an slightly out-of-date HEAD) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 13:39:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 13:39:52 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.414e5b42b1aef3184b92374602d5446a@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10656 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "93098974.png" added. [http://smartmiltoys.com/kidkraft-train-table/ http://smartmiltoys.com /kidkraft-train-table/] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 16:40:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 16:40:10 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.e98d27a8147d398e173df42bb820be1f@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"bb956eb8d8774613c1e311655f1359a91a84765b/ghc" bb956eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb956eb8d8774613c1e311655f1359a91a84765b" Add asserts to other substitution functions This adds asserts to `substTys`, `substCo` and `substCos` in the same spirit as already existing asserts on `substTy`, protecting every possible entry point to `subst_ty` and `subst_co`. I've replaced the violators with unchecked versions. Test Plan: ./validate --slow Reviewers: simonpj, goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1862 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 19:26:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 19:26:53 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.fb81a50d1cc7a18d4c3b00625389d5f8@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Comment (by alfa07): Alas building with ghc-8 didn't help (I have rebuilt it from HEAD and checked that your diff is in): ? stack --skip-ghc-check --system-ghc --stack-yaml stack-8.yaml ghci GLUtil-0.8.8: build GLUtil-0.8.8: copy/register line-segment-intersection-0.1.0.0: configure line-segment-intersection-0.1.0.0: build line-segment-intersection-0.1.0.0: copy/register Completed 2 action(s). The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 8.1.20160129: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160129 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc55362_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc55362_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc55362_0/libghc_25.dylib 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 Jan 30 20:26:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 20:26:40 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.613a858217511c021bd4ff54493f1fd0@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 11371 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: I'm going to dig more, but I expect I might not know how to best fix this. In general how does the typechecker deal with types that can get exponential? The part of the code that generates such types is: {{{ newtype VoidBad a = VoidBad (VoidBad (a,a)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 21:13:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 21:13:59 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.01288ee33a0cf19b87da2eb43eafa90e@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: | DuplicateRecordFields, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T11328 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * testcase: => ghci/should_run/T11328 * status: new => patch * differential: => Phab:D1870 * component: Compiler => GHCi * milestone: 8.2.1 => 8.0.1 Comment: Fortunately this one was an easy fix. I noticed that generated names (e.g. beginning with `$tc` or `$tr`) were turning up in the autocomplete after defining datatypes interactively, so I fixed that too. It's a tiny patch, so maybe worth backporting to 8.0.1? But the bug is fairly obscure, so not a disaster if that's too much trouble. > Even if you enable `OverloadedLabels`, the `#labels` don't show up in the auto completion. I've not changed this; I think it's the correct behaviour. A `#label` is not an identifier, it's a separate syntactic form, and there's no obvious basis for auto-completing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 21:30:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 21:30:28 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.4eab05ff3c6e27a256c8b3977a21f9b8@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective 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) Comment: I don't think this is a soundness problem: FC does not have infinite types, only finite approximations thereof, and there is no way to prove the equality of any finite expansions of `F Bool` and `F Char`. Here's a hand-wavy argument that injectivity of `F` is admissible... Suppose we have a minimal coercion `F s ~ F t`. Then either this is by congruence of type family application (in which case we have `s ~ t`), or it uses the axiom for `F` to expand both sides, so there is a smaller coercion `[F s] ~ [F t]` and hence of `F s ~ F t` (which contradicts the assumption that our original coercion was minimal). [The ordering on coercions is left as an exercise to the reader.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 22:02:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 22:02:12 -0000 Subject: [GHC] #11519: Inferring non-tau kinds Message-ID: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While up to my usual type-level shenanigans, I found that I want this definition: {{{ data TypeRep (a :: k) -- abstract data TypeRepX :: (forall k. k -> Constraint) -> Type where TypeRepX :: forall k (c :: forall k'. k' -> Constraint) (a :: k). c a => TypeRep a -> TypeRepX c }}} Note `TypeRepX`'s higher-rank kind. The idea is that I want to optionally constrain `TypeRepX`'s payload. Without using a higher-rank kind, the constraint would necessary fix the kind of the payload, and I don't want that. For example, I sometimes use `TypeRepX ConstTrue`, where {{{ class ConstTrue (a :: k) instance ConstTrue a }}} This actually works just fine, and I've been using the above definition to good effect. But then I wanted a `Show` instance: {{{ instance Show (TypeRep a) -- elsewhere instance Show (TypeRepX c) where show (TypeRepX tr) = show t }}} Looks sensible. But GHC complains. This is because it tries to infer `c`'s kind, by inventing a unification variable and then unifying. But this doesn't work, of course, because `c`'s kind is not a tau-type, so unification fails, lest we let impredicativity sneak in. What's particularly vexing is that, even if I annotate `c` with the correct kind, unification ''still'' fails. This is because that `c` is a ''usage'' of `c`, not a ''binding'' of `c`. Indeed, there is no place in an instance declaration to bind a type variable explicitly, so I have no recourse. I'm not sure what the solution is here. Somehow, it feels that inferring a non-tau kind for `c` is perfectly safe, because the kind is known from the use of `TypeRepX`. This would allow me to drop the kind annotation in the definition of `TypeRepX`, which looks redundant to me. But I'm not fully sure about this assumption. At the least, we could introduce a spot for explicit binding of type variables in instance declarations. I think, actually, I just figured it out. Use `ExpType`s when kind- checking types. Then I think the normal bidirectional thing (actually already implemented) will do the Right Thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 22:12:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 22:12:49 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.911deece86dd8944eba60c1abf1b2fe5@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: I think it would be very sensible to permit type variable bindings in instance declarations. The syntax could be {{{#!hs instance forall (c :: forall k . k -> Constraint) . Show (TypeRepX c) where }}} which is hardly beautiful, but gets the job done. My thesis had another example of this need (if we had a `pi` quantifier, of course...): {{{#!hs instance pi (n :: Nat) . Monad (Vec n) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 30 22:28:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jan 2016 22:28:21 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.0ba7c58010ff3c41afd8ce80f9f6753f@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective 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): Perhaps this counterexample is why I could never finish that proof. I don't believe I ever reached for an assumption of finite types, probably conflating the notion of finite types with terminating type families. What bothers me is that we have no guarantee that FC types are indeed finite. On paper, we just define types inductively and are done with it. But how does this play out in the implementation? Recall that infinite types have led to segfaults before: #8162. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 06:16:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 06:16:18 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.e25b8ff48246b2bef29a49a5b9c9f684@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Comment (by alfa07): Using patch as Simon suggested fixes issue after recompiling ghc-7.10.3 with it (rts/Linker.c): {{{ - hdl = dlopen(dll_name, RTLD_LAZY|RTLD_LOCAL); /* see Note [RTLD_LOCAL] */ + hdl = dlopen(dll_name, RTLD_LAZY | RTLD_GLOBAL); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 07:02:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 07:02:54 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.b48d55e32d1ada5ada4f977db94f0784@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Comment (by trommler): I reformatted the compiler output below. Could you perhaps attach the contents of the directory where you invoke `stack` so I can have a look and perhaps reproduce? Replying to [comment:4 alfa07]: > Alas building with ghc-8 didn't help (I have rebuilt it from HEAD and checked that your diff is in): {{{ ? stack --skip-ghc-check --system-ghc --stack-yaml stack-8.yaml ghci GLUtil-0.8.8: build GLUtil-0.8.8: copy/register line-segment-intersection-0.1.0.0: configure line-segment-intersection-0.1.0.0: build line-segment-intersection-0.1.0.0: copy/register Completed 2 action(s). The following GHC options are incompatible with GHCi and have not been passed to it: -threaded -Odph Using main module: 1. Package `line-segment-intersection' component exe:demo with main-is file: /Users/maxim/Dev/ComputationGeometry/LineSegmentIntersection/app/Main.hs Configuring GHCi with the following packages: line-segment-intersection, GLUT, GLUtil, boundingboxes, freetype-simple, freetype2 GHCi, version 8.1.20160129: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160129 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc55362_0/libghc_25.dylib, 5): Symbol not found: _bdf_driver_class Referenced from: /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc55362_0/libghc_25.dylib Expected in: flat namespace in /var/folders/dz/lm9jncs90nq0vn_5j7xhpg2xqyfj66/T/ghc55362_0/libghc_25.dylib 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 Sun Jan 31 07:18:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 07:18:13 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.40db8f334ec9391ccebafcf1afcebd6d@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Comment (by alfa07): Here is the link to the tar.gzipped folder: [https://www.dropbox.com/s/q468h8zvht7w0ln/line-segment- intersection.tar.gz?dl=0] Can't attach it as the size is larger than allowed 256k. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 08:40:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 08:40:19 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.ab9120b4f82e93e791f3c2ff544920f5@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------+--------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic linking Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Comment (by trommler): Replying to [comment:5 alfa07]: > Using patch as Simon suggested fixes issue after recompiling ghc-7.10.3 with it (rts/Linker.c): > > {{{ > - hdl = dlopen(dll_name, RTLD_LAZY|RTLD_LOCAL); /* see Note [RTLD_LOCAL] */ > + hdl = dlopen(dll_name, RTLD_LAZY | RTLD_GLOBAL); > }}} This patch breaks `ghci/scripts ghci058` at least on Linux and this is to be expected given ELF symbol resolution semantics. See the note referenced in note `RTLD_LOCAL` for a more detailed explanation. Did you run `./validate` on MacOS with the proposed patch applied? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 10:00:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 10:00:21 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.f5bab2cf8828581830e451963dc9ce17@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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 bgamari): One bit of trickiness that I've encountered while looking at this is the that fact Core Lint disallows unsaturated applications of unlifted types. So, for instance, if we have, {{{#!hs data TTTypeRep (a :: k) where TrTyCon :: !Fingerprint -> !(TyCon a) -> TTypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). !Fingerprint -> TTypeRep (a :: k1 -> k2) -> TTypeRep (b :: k1) -> TTypeRep (a b) }}} And we ask for `Typeable (Array# Int)`, we will attempt to decompose `Array# Int` and end up with a subterm, {{{#!hs array#Rep :: TTypeRep Array# array#Rep = TrTyCon @(* -> #) @Array# fprint array#TyCon }}} in the resulting representation, which currently fails Core Lint due to, {{{#!patch diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index 26e7257..861a9bc 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -1042,7 +1042,7 @@ lintType ty@(TyConApp tc tys) = lintType ty' -- Expand type synonyms, so that we do not bogusly complain -- about un-saturated type synonyms - | isUnliftedTyCon tc || isTypeSynonymTyCon tc || isTypeFamilyTyCon tc + | isTypeSynonymTyCon tc || isTypeFamilyTyCon tc -- Also type synonyms and type families , length tys < tyConArity tc = failWithL (hang (text "Un-saturated type application") 2 (ppr ty)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 12:54:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 12:54:04 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.d4a33aafe2a4393283b68afedacc7486@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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 bgamari): Another question that I stumbled upon is whether we should provide something akin to `Data.Typeable.splitPolyTyConApp`, which provides access to the kind arguments which a type constructor was applied to. In some cases there may be no way to extract these kinds otherwise. Consider the following, {{{#!hs data Proxy (a :: k) = Proxy proxyIntRep :: TypeRep (Proxy Int) proxyIntRep = typeRepKind proxyIntRep data Compose (f :: k1 -> *) (g :: k2 -> k1) (x :: k2) = Compose (f (g a)) data Id a = Id a composeIdIdRep :: TypeRep (Compose Id Id) composeIdIdRep = typeRep -- The plan currently allows data AppResult (t :: k) where App :: TypeRep a ? TypeRep b ? AppResult (a b) splitApp :: TypeRep a ? Maybe (AppResult a) typeRepKind :: TypeRep (a :: k) -> TypeRep k -- Allowing one to get concrete kind of Proxy proxyIntKind :: TypeRep (* -> *) proxyIntKind = typeRepKind proxyIntRep -- In the case of `Proxy Int` we can extract the first kind argument, -- `k ~ *`, trivially via function decomposition as it is the -- kind of the first type. pattern TRFun :: fun ~ (arg -> res) => TTypeRep arg -> TTypeRep res -> TTypeRep fun -- In contrast, determining the instantiation of `k1` in the case of -- `Compose Id Id` is not possible since it is not exposed in -- the resulting kind. composeIdIdKind :: TypeRep (* -> *) composeIdIdKind = kindRep composeIdIdRep }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 13:01:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 13:01:39 -0000 Subject: [GHC] #11520: GHC falls into a hole Message-ID: <046.a2116e67b07177218d33d38f3453d162@haskell.org> #11520: GHC falls into a hole -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes, PolyKinds, TypeInType, GADTs, UndecidableSuperClasses #-} module Play where import GHC.Types hiding (TyCon) data TyCon (a :: k) = TyCon data TypeRep (a :: k) where TypeCon :: forall (a :: k). TyCon a -> TypeRep k -> TypeRep a TypeApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep a -> TypeRep b -> TypeRep (a b) class Typeable k => Typeable (a :: k) where typeRep :: TypeRep a data Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) composeTyCon :: TyCon Compose composeTyCon = TyCon Fingerprint "Compose" instance (Typeable f, Typeable (g :: k), Typeable k) => Typeable (Compose f g) where typeRep = TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) typeRep instance (Typeable f, Typeable g, Typeable a) => Typeable (Compose f g a) where typeRep = TypeApp (TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) typeRep) typeRep }}} fails with {{{ ?> :load Bug.hs [1 of 1] Compiling Play ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160122 for x86_64-unknown-linux): fvProv falls into a hole {abet} 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 Sun Jan 31 13:02:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 13:02:37 -0000 Subject: [GHC] #11520: GHC falls into a hole In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.0bcb4a54125427fc3995449d8c97af71@haskell.org> #11520: GHC falls into a hole -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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 bgamari): * failure: None/Unknown => Incorrect warning at compile-time @@ -0,0 +1,2 @@ + This non-sense, + New description: This non-sense, {{{#!hs {-# LANGUAGE RankNTypes, PolyKinds, TypeInType, GADTs, UndecidableSuperClasses #-} module Play where import GHC.Types hiding (TyCon) data TyCon (a :: k) = TyCon data TypeRep (a :: k) where TypeCon :: forall (a :: k). TyCon a -> TypeRep k -> TypeRep a TypeApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep a -> TypeRep b -> TypeRep (a b) class Typeable k => Typeable (a :: k) where typeRep :: TypeRep a data Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) composeTyCon :: TyCon Compose composeTyCon = TyCon Fingerprint "Compose" instance (Typeable f, Typeable (g :: k), Typeable k) => Typeable (Compose f g) where typeRep = TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) typeRep instance (Typeable f, Typeable g, Typeable a) => Typeable (Compose f g a) where typeRep = TypeApp (TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) typeRep) typeRep }}} fails with {{{ ?> :load Bug.hs [1 of 1] Compiling Play ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160122 for x86_64-unknown-linux): fvProv falls into a hole {abet} 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 Sun Jan 31 13:05:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 13:05:56 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature (was: GHC falls into a hole) In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.11fecb44a4c46a9fddb800a8e9747320@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -1,1 +1,2 @@ - This non-sense, + If one provides an incorrect kind signature GHC throws up. For instance, + this non-sense, @@ -11,2 +12,0 @@ - data TyCon (a :: k) = TyCon - @@ -14,1 +13,1 @@ - TypeCon :: forall (a :: k). TyCon a -> TypeRep k -> TypeRep a + TypeCon :: forall (a :: k). String -> TypeRep k -> TypeRep a @@ -25,3 +24,1 @@ - composeTyCon :: TyCon Compose - composeTyCon = TyCon Fingerprint "Compose" - + -- Note how the kind signature on g is incorrect @@ -30,2 +27,1 @@ - typeRep = TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) - typeRep + typeRep = undefined @@ -33,4 +29,0 @@ - instance (Typeable f, Typeable g, Typeable a) => Typeable (Compose f g a) - where - typeRep = TypeApp (TypeApp (TypeApp (TypeCon composeTyCon typeRep) - typeRep) typeRep) typeRep New description: If one provides an incorrect kind signature GHC throws up. For instance, this non-sense, {{{#!hs {-# LANGUAGE RankNTypes, PolyKinds, TypeInType, GADTs, UndecidableSuperClasses #-} module Play where import GHC.Types hiding (TyCon) data TypeRep (a :: k) where TypeCon :: forall (a :: k). String -> TypeRep k -> TypeRep a TypeApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep a -> TypeRep b -> TypeRep (a b) class Typeable k => Typeable (a :: k) where typeRep :: TypeRep a data Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) -- Note how the kind signature on g is incorrect instance (Typeable f, Typeable (g :: k), Typeable k) => Typeable (Compose f g) where typeRep = undefined }}} fails with {{{ ?> :load Bug.hs [1 of 1] Compiling Play ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160122 for x86_64-unknown-linux): fvProv falls into a hole {abet} 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 Sun Jan 31 13:07:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 13:07:09 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.45b7385f90ca2fba8cb210e50d9a3fbd@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -12,6 +12,1 @@ - data TypeRep (a :: k) where - TypeCon :: forall (a :: k). String -> TypeRep k -> TypeRep a - TypeApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). - TypeRep a - -> TypeRep b - -> TypeRep (a b) + data TypeRep (a :: k) @@ -28,1 +23,0 @@ - New description: If one provides an incorrect kind signature GHC throws up. For instance, this non-sense, {{{#!hs {-# LANGUAGE RankNTypes, PolyKinds, TypeInType, GADTs, UndecidableSuperClasses #-} module Play where import GHC.Types hiding (TyCon) data TypeRep (a :: k) class Typeable k => Typeable (a :: k) where typeRep :: TypeRep a data Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) -- Note how the kind signature on g is incorrect instance (Typeable f, Typeable (g :: k), Typeable k) => Typeable (Compose f g) where typeRep = undefined }}} fails with {{{ ?> :load Bug.hs [1 of 1] Compiling Play ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160122 for x86_64-unknown-linux): fvProv falls into a hole {abet} 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 Sun Jan 31 13:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 13:18:51 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.cdfe52c4cc0fed462754af8348e5622d@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by thomie): This commit causes the following Travis failures with DEBUG=YES: {{{ Unexpected failures: ../../libraries/base/tests/IO hClose002 [exit code non-0] (normal) ../../libraries/base/tests/IO hClose003 [exit code non-0] (normal) ../../libraries/base/tests/IO hDuplicateTo001 [exit code non-0] (normal) }}} See https://s3.amazonaws.com/archive.travis-ci.org/jobs/105899161/log.txt Here is one of them: {{{ =====> hClose002(normal) 4736 of 5007 [0, 0, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( hClose002.hs, hClose002.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160130 for x86_64-unknown-linux): ASSERT failed! CallStack (from ImplicitParams): assertPprPanic, called at compiler/types/TyCoRep.hs:1903:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2047:17 in ghc:TyCoRep substCo, called at compiler/basicTypes/MkId.hs:698:28 in ghc:MkId in_scope InScope {} tenv [a1oW :-> dev_a1Z8, a1oX :-> enc_state_a1Z9, a1oY :-> dec_state_a1Za] tenvFVs [a1Z8 :-> dev_a1Z8, a1Z9 :-> enc_state_a1Z9, a1Za :-> dec_state_a1Za] cenv [] cenvFVs [] tys [] cos [N:IORef[0] _N] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 13:28:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 13:28:42 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.902cc4458e591790a283d3b68b1fd9f1@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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): Re comment:7: Given our ideas in #11471, it's quite possible that the saturation check has gone stale. It does take a bit of Hard Thought, but my guess is that we can lift this restriction. Re comment:8: I'm afraid there are a few bugs in your code, and it's hard to disentangle what you're getting at. * The body of `proxyIntRep` is not what you mean. Perhaps you just meant `typeRep`? * The type of `proxyIntKind` is wrong. Why should it be `TypeRep (* -> *)`? I would think it's just plain old `*`, which is the kind of `Proxy Int`. * Your `TRFun` pattern would seem to want pattern signature `() => fun ~ (arg -> res) => TTypeRep arg -> TTypeRep res -> TTypeRep fun`, no? That is, the equality is provided, not required. * Are you worried about decomposing `Proxy Int` itself? As in `case splitApp proxyIntRep of App trProxy _trInt -> typeRepKind trProxy`? But that would just be `* -> *` because the `Proxy` would still be specialized to `*`. Does this help to clarify? We absolutely need to only build kind- monomorphic `TypeRep`s, as described in the paper, but I don't see where things go awry under this scheme. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 15:01:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 15:01:27 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.f27b03b997317ff40dea2b9d006182e0@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b61f5f734d08fe9cdca3ac06560fc15e97aa77ab/ghc" b61f5f73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b61f5f734d08fe9cdca3ac06560fc15e97aa77ab" Put docs in /usr/share/doc/ghc- `make install` puts libraries in a direcory containing the version number. Do the same for the docs, such that multiple installs can live side-by-side. Delete unused ghcdocdir. Test Plan: ``` ./boot ./configure make show! VALUE=docdir ``` Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1868 GHC Trac Issues: #11354 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 15:02:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 15:02:51 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.462abaa0784445628b32ac1458c45ec0@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Build System | Version: 7.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge Comment: Should be safe to merge, but please use your own judgement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 15:03:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 15:03:04 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.aa164bf92f7d876783dc5ee56be67485@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 15:37:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 15:37:06 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES Message-ID: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 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 running `validate --slow`, which also builds libraries the profiling way now (see #11496), a lot of tests are failing for test ways `profasm` and `profthreaded`. To reproduce, set `BUILD_PROF_LIBS=YES` in `mk/build.mk` and run `make` in toplevel directory. Then run: `make test CLEANUP=1 WAY=profasm TEST="T2552 cgrun045 T5626 cgrun051 cgrun016 cgrun059 T2120 T11193 T9078 overflow3 overflow2 overflow1 T10728 T7919 T11049 T5550 conc021 SplicesUsed T5654b-O1 T5654b-O0 T2552 Rules1 T3220 T7837 ColInference3 hpc_fork ffi008 fptrfail01 TH_spliceViewPat overloadedrecfldsrun04 overloadedlabelsrun04 arr004 arr007 arr008 arr003 assert T8089 readFloat stm060 T5628 tough T7411 qq007 qq008 qq009"` (some of the above tests might be failing for other reasons, but most should be about this issue) Here is an example failure: {{{ --- ./codeGen/should_run/cgrun045.stderr.normalised 2016-01-31 16:34:03.831816885 +0100 +++ ./codeGen/should_run/cgrun045.run.stderr.normalised 2016-01-31 16:34:03.831816885 +0100 @@ -1,3 +1,6 @@ cgrun045: hello world! CallStack (from HasCallStack): error, called at cgrun045.hs:: in :Main \ No newline at end of file +CallStack (from -prof): + Main.main (cgrun045.hs:6:1-52) + Main.CAF () \ No newline at end of file *** unexpected failure for cgrun045(profasm) }}} Is this expected behavior? The double callstacks look a little weird to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 16:10:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 16:10:40 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.822636343ac4eb8024bb6f6e6ce01eb2@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 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 gridaphobe): * cc: simonmar (added) Comment: This is expected, simonmar added the `-prof` stack traces to `error` as well (when available). The rationale is that `HasCallStack` will usually include call-sites close to the error, but not further up the chain, so we augment the trace with `-prof` if we can. The formatting is a bit unfortunate, but I think we have to distinguish the two sources somehow, it's not at all clear how to stitch them together in a consistent and sensible manner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 16:17:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 16:17:21 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.ac7a545189421a02692dbdf8017c0b40@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 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 thomie): Ok, fine. But the tests need fixing somehow. They should pass for all test ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 17:24:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 17:24:36 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.056801f51ca467d0374fee62969aacd6@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------------+------------------------------------- Reporter: alfa07 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic | linking Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: infoneeded => new * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * blockedby: => 11238 Comment: Replying to [comment:7 alfa07]: > Here is the link to the tar.gzipped folder: [https://www.dropbox.com/s/q468h8zvht7w0ln/line-segment- intersection.tar.gz?dl=0] Can't attach it as the size is larger than allowed 256k. Thank you! I can reproduce the issue on Linux with a GHC that has the #10458 patch: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc29316_0/libghc_25.so: undefined symbol: tt_driver_class }}} I see a different symbol missing but the missing symbol should come from `freetype2`, too. Redesign of dynamic linking should fix this. So marking as blocked on that ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:04:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:04:18 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.964ba766f0c49aa4f41f24ca2e6cc0b4@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective 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 jstolarek): > I think the right solution here would be to drop equation (7) from our algorithm in the paper. On a second thought I don't think this would be good idea. Doing this would mean that using any type family in the RHS is prohibited for injective type families and we definitely don't want that for generalized injectivity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:11:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:11:36 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.5ca0c3080c9fc33a873c0030c32c63ef@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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 bgamari): Re comment:9: Oh dear, yes, that code is just non-sense. Sorry about that, it seems I should have read through it before hitting submit. Let's try again: The principle concern was that the current Typeable scheme provides a way for users to query the kinds at which a TyCon was instantiated via `Data.Typeable.splitPolyTyConApp`. The current New Typeable plan doesn't seem to provide any way to accomplish this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:33:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:33:15 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.e21f3cdaa72ff8be6e37b4ab91b1ad33@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: #10000 | Differential Rev(s): Phab:D652, Wiki Page: | Phab:D757 -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #10000 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:36:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:36:01 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.95d0b555246e161ad679599e17b24901@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1864 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Geoffrey Mainland ): In [changeset:"669cbef03c220de43b0f88f2b2238bf3c02ed64c/ghc" 669cbef0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="669cbef03c220de43b0f88f2b2238bf3c02ed64c" Fix Trac issue #11487. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:36:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:36:01 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.237ba6ca21f82a3f7a5eef688e0972c6@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1864 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Geoffrey Mainland ): In [changeset:"6544f8de1ed575378f14b82a2eaa06cab58b2d65/ghc" 6544f8de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6544f8de1ed575378f14b82a2eaa06cab58b2d65" Properly track live registers when saving the CCCS. Summary: When saving the CCCS, we now correctly track the set of live registers and pass them to the jump_SAVE_CCCS macro. This is now a variadic macro, but variadic macros are supported by GCC since 3.0 and by all versions of clang, so this should not be a problem. Test Plan: ./validate with the following build options: ``` BuildFlavour = quick-llvm SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage ``` Reviewers: bgamari, simonmar, austin, rwbarton, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1864 GHC Trac Issues: #11487 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:38:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:38:05 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.d293f929e7e3caf6b65391e60572ef44@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 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:D1864 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gmainland): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:38:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:38:59 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.ac68573f08f26f8ef6dacfd79dcfa13a@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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 bgamari): Also, Richard pointed out in IRC that the TyCon representations that I produce in my current implementation are too weakly typed and would mean that we #10000 (also #9858) would remain (at least if we allowed something like `TyCon -> TypeRep`, which the current `Typeable` does not). To fix this, we need to make the user provide type representations for the concrete kinds he wishes to instantiate at before giving him a representation. For instance, `Proxy`'s representation would look like, {{{#!hs data TyCon a proxyTyCon :: TypeRep k -> TyCon (Proxy :: k -> *) proxyTyCon = ... }}} However, this makes an already complex story even more complex. Even worse, it will make all module with type definitions pay even more in both compilation time and code size due to the lambdas. `TyCon`s are currently nice pure records with quite efficient representations. It would be nice to retain this property. In light of this, perhaps it would be reasonable to consider an alternative: == An alternative: TyCon entirely == An appealing alternative here would be to remove `TyCon` from the user- facing interface entirely. This would mean that it can remain unindexed, `TyCon` is already more-or-less an implementation detail and I can't think of any reason why a `TypeRep` wouldn't do. Removing `TyCon` from the interface would be a substantial simplification to the scheme and neither Richard nor I could think of any reason why it is strictly necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 31 18:46:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Jan 2016 18:46:53 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.8605fee604c6bcaadd2255ae756f45ec@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | 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 bgamari): Actually, I forgot about a small wrinkle. `TyCon` is currently the only way one can query for the names of the package and module where a type constructor is defined. Perhaps we should just stick with the status quo: provide `TyCon` in unindexed form as essentially a record of basic metadata about a type constructor (perhaps even hiding the fingerprint, so users don't get any funny ideas). The important thing is that we don't provide a way to create a `TypeRep` from a `TyCon`. So long as this is the case the weakly-typed nature of `TyCon` should pose no threat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 17:14:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 17:14:48 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.88aab02f240b8a8f9b9a6c5e2babaa8c@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Comment (by simonmar): Ugh, I think `-maxN` is worse than `-Nmax` because of the weird overlap with `-m`. I think `-Nmax` was completely fine (but I was too late!). The documentation could read "use at most processors". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 18:03:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 18:03:05 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.8caae05328d89be97ebba989c180793d@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:21 simonmar]: > Ugh, I think `-maxN` is worse than `-Nmax` because of the weird overlap with `-m`. I think `-Nmax` was completely fine (but I was too late!). The documentation could read "use at most processors". It's never too late, but you'll have to convince hvr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 5 18:04:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jan 2016 18:04:56 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.60fcb74501aa3636876fc13c3ec7bbfe@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Comment (by rwbarton): Probably won't help, but I agree that the original `-Nmax` is clearly the best name. -- Ticket URL: GHC The Glasgow Haskell Compiler