From ghc-devs at haskell.org Wed Feb 1 02:02:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 02:02:38 -0000 Subject: [GHC] #12905: Core lint failure with pattern synonym and levity polymorphism In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.5b77f921fadfab141aae4aafbb32478f@haskell.org> #12905: Core lint failure with pattern synonym and levity polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: duplicate | LevityPolymorphism, typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #11714 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #11714 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 02:19:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 02:19:38 -0000 Subject: [GHC] #13204: Core Lint error running testsuite with DEBUG way In-Reply-To: <047.381ba5a00f4e3199e228a3db6ee351e7@haskell.org> References: <047.381ba5a00f4e3199e228a3db6ee351e7@haskell.org> Message-ID: <062.93fb910ee1ec7a2cfd8ae44d94b852b7@haskell.org> #13204: Core Lint error running testsuite with DEBUG way -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 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): Phab:D3051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3051 Comment: I suspect this will be resolved by Phab:D3051. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 04:13:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 04:13:46 -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.ff29992dfbff47d7f19cb3e412203b68@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | 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): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Doug310): Thank you team, I look forward to trying this in the next release!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 08:46:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 08:46:07 -0000 Subject: [GHC] #13213: Lifting thunks out of thunks to reduce their size. In-Reply-To: <046.1689ccc048c57b0152cdb9ec365a6ae5@haskell.org> References: <046.1689ccc048c57b0152cdb9ec365a6ae5@haskell.org> Message-ID: <061.221b8a3254725af7f9d8af3944389afa@haskell.org> #13213: Lifting thunks out of thunks to reduce their size. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 10:10:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 10:10:53 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories In-Reply-To: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> References: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> Message-ID: <064.9857c0e526245d43127375293796cdd2@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): Are you absolutely sure that's correct? Windows can handle forward slashes, but they don't count as file/folder separators. You can observe in my ticket report how GHC calls cpphs with incorrect path to the file, but I don't see how cpphs is responsible how it's called: {{{ "-include" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include\ghcversion.h" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 10:19:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 10:19:31 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories In-Reply-To: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> References: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> Message-ID: <064.5f5433f3e843c4fba9b3d16550194502@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Replying to [comment:4 domenkozar]: > Windows can handle forward slashes, but they don't count as file/folder separators. Wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 10:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 10:37:02 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories In-Reply-To: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> References: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> Message-ID: <064.27f28b2db0b47cdf8a41c2ac6f7a03ed@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): The path isn't incorrect, It's a perfectly valid Windows path. DOS path separator character `\` isn't required by the API at all. The behavior you're alluding to is that of DOS or command.com, not NT. The page I pointed you to explicitly says: {{{ Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections. }}} You can see an overview here https://en.wikipedia.org/wiki/Path_%28computing%29 or you can just experiment yourself: {{{ C:\Users\tamar\Desktop>mkdir foo C:\Users\tamar\Desktop>echo "hello world" > foo/test.txt C:\Users\tamar\Desktop>dir foo Volume in drive C is Windows Volume Serial Number is ... Directory of C:\Users\tamar\Desktop\foo 01/02/2017 10:17 . 01/02/2017 10:17 .. 01/02/2017 10:17 16 test.txt 1 File(s) 16 bytes 2 Dir(s) 45,293,834,240 bytes free }}} The error is being generated by `cpphs` and we've given it a valid path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 10:55:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 10:55:15 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories In-Reply-To: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> References: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> Message-ID: <064.f280d7661bd83f1e521652981d275201@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): https://github.com/malcolmwallace/cpphs/issues/8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 11:13:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 11:13:15 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories In-Reply-To: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> References: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> Message-ID: <064.5e33b5e88ab316f7042b54703ad12325@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 12:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 12:13:08 -0000 Subject: [GHC] #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) In-Reply-To: <045.69add10eda8bd8d6b058cda01bcfaac3@haskell.org> References: <045.69add10eda8bd8d6b058cda01bcfaac3@haskell.org> Message-ID: <060.d66993b9c9ccc6f8fb3f816f21591daf@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T13056 Blocked By: | Blocking: Related Tickets: #12234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Would the much smaller example be a good perf test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 13:20:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 13:20:53 -0000 Subject: [GHC] #13171: panic on negative literal in case on Word In-Reply-To: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> References: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> Message-ID: <062.d299ffb89b9982c576b01c1ba6a04697@haskell.org> #13171: panic on negative literal in case on Word -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Reid this looks like an area you are familiar with. Are you planning to look into it? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 14:54:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 14:54:59 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg Message-ID: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just for fun I tried to compile Agda using `-XStrict`. Result: {{{ [...] [235 of 324] Compiling Agda.Syntax.Translation.InternalToAbstract [...] ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for i386-unknown-linux): push_bang_into_newtype_arg {} }}} To reproduce (using GHC 8.0.2): {{{ git clone https://github.com/agda/agda.git cd agda git checkout f8a24fe9ed50e4287bc7308e2b3da4615db87aa8 cabal install --ghc-options=-XStrict --constraint=EdisonCore==1.3.1.1 --constraint=EdisonAPI==1.3.1 --constraint=base==4.9.1.0 --constraint=ghc- prim==0.5.0.0 --constraint=rts==1.0 --constraint=integer-gmp==1.0.0.1 --constraint=mtl==2.2.1 --constraint=transformers==0.5.2.0 --constraint=QuickCheck==2.9.2 --constraint=containers==0.5.7.1 --constraint=array==0.5.1.1 --constraint=deepseq==1.4.2.0 --constraint=random==1.1 --constraint=time==1.6.0.1 --constraint=template- haskell==2.11.1.0 --constraint=ghc-boot-th==8.0.2 --constraint=pretty==1.1.3.3 --constraint=tf-random==0.5 --constraint=primitive==0.6.1.0 --constraint=binary==0.8.3.0 --constraint=bytestring==0.10.8.1 --constraint=boxes==0.1.4 --constraint=split==0.2.3.1 --constraint=data-hash==0.2.0.1 --constraint=directory==1.3.0.0 --constraint=filepath==1.4.1.1 --constraint=unix==2.7.2.1 --constraint=edit-distance==0.2.2.1 --constraint=equivalence==0.3.1 --constraint=STMonadTrans==0.3.4 --constraint=transformers-compat==0.5.1.4 --constraint=geniplate- mirror==0.7.4 --constraint=gitrev==1.2.0 --constraint=process==1.4.3.0 --constraint=hashable==1.2.5.0 --constraint=text==1.2.2.1 --constraint=hashtables==1.2.1.0 --constraint=vector==0.11.0.0 --constraint=haskeline==0.7.3.0 --constraint=terminfo==0.4.0.2 --constraint=ieee754==0.7.9 --constraint=monadplus==1.4.2 --constraint =murmur-hash==0.1.0.9 --constraint=parallel==3.2.1.0 --constraint=regex- tdfa==1.2.2 --constraint=parsec==3.1.11 --constraint=regex-base==0.93.2 --constraint=strict==0.3.2 --constraint=unordered-containers==0.2.7.2 --constraint=xhtml==3000.2.1 --constraint=zlib==0.6.1.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 15:20:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 15:20:00 -0000 Subject: [GHC] #12817: Degraded performance with constraint synonyms In-Reply-To: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> References: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> Message-ID: <062.9c62e30233ce15f6114d8d2486e21575@haskell.org> #12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 RyanGlScott): Does the fix for #12791 (748b79741652028827b6225c36b8ab55d22bdeb0) help here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 15:38:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 15:38:13 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.9efc65206b4fe88826100d332d5365fb@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks. Here is a small reproduction. {{{ {-# LANGUAGE Strict #-} newtype F = F Int foo (F {}) = () }}} The fix looks to be very easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 15:42:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 15:42:49 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.455c5568de71a6d81197f575c22822fa@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The problem in the example is in the instance for `Reify MetaId Expr` if this is blocking you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:27:54 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret Message-ID: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- We started getting the following from our app; though it's not reliably reproducible: {{{ internal error: stg_ap_pppppp_ret (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort }}} Unfortunately I cannot share code, nor I can upgrade to GHC 8.0.2 due to work environment restrictions. My apologies for the worst bug report. Neither google nor Trac searches produced anything related. I'm wondering if anybody has seen this, or have any ideas where to look at. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:33:45 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.cc25c69173138f553edec75012a34a18@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:34:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:34:31 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.aab8cc88176a34fc24fbedc6cf5346b6@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The panic indicates that you tried to apply something that wasn't a function (to six arguments). A likely cause is heap corruption, possibly due to a misbehaving FFI function or something of that sort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:34:37 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.c5209b4fe08ea6a9fc823c006006af5b@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What is the fix? Generally we are transforming {{{ f !(F n) = ... }}} into {{{ f (F !n) = ... }}} What if it's this? {{{ f !(F {}) = ... }}} We do still need to be strict. So perhaps we transform to {{{ f (F !_) = ... }}} Looks ok to me (with a Note). Could you execute on that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:40:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:40:04 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.03c5d1892a9094059f47991481b0e007@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Thanks! There is no FFI involved in the app; pure Haskell. The dependencies also look quite benign: {{{ base >= 3 && < 5 , array, bytestring, binary, containers, directory, edit- distance , filepath, haskeline, mtl, process, time, old-time, old-locale , text, utf8-string, xml, zlib, unix, split, gitrev, deepseq, git-date }}} though of course I don't know if any of these might be doing some FFI. (Perhaps `git-date` does.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:42:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:42:47 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.e07aa4ef7592c40a5693ddeefa2f7bd8@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D3057 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:43:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:43:00 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.a4c812aaea701fb3b4c710711d896fcd@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): You can also try building with `-debug` (purely a linktime option, no need to recompile any modules) and run with `+RTS -DS`, which will turn on various runtime sanity checks which might find the issue sooner. See Debugging/RuntimeSystem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 17:49:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 17:49:06 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.5893368689e8368c3ed083da59de7afa@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Also try `-dcore-lint -dstg-lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:04:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:04:33 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.6e24e14d8280e0b056408e1ccc5f8a2e@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:09:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:09:06 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.f15a8dac71ec611f16826edfdcc4e38b@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): @goldfire: Thanks! Lint indeed finds an issue: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : warning: [RHS of help2 :: [([Char], [Char], [Char])]] In a function application, function type doesn't match arg types: Function type: [Char] -> ((State -> Exp -> State# RealWorld -> (# State# RealWorld, State #)) :: *) ~R# ((State -> Exp -> IO State) :: *) => [Char] -> [Char] -> [([Char], (State -> Exp -> IO State, State -> [Char], [Char] -> [Completion], [Char], [Char]))] -> [([Char], [Char], [Char])] Arg types: [Char] (() :: *) ~# (() :: *) [Char] [Char] [(String, (State -> Exp -> IO State, State -> String, String -> [Completion], String, String))] Expression: help_$sgo settables92 coercionToken# settables81 settables80 settables1 }}} I've created a gist for the whole output (which is quite large): https://gist.github.com/LeventErkok/55aa19176d6adeb48eef56f39019c202 Is it the second argument that's having an issue here? Perhaps I'm reading it wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:14:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:14:40 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.2458e380c08592c458efe37cb7fa0210@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Unfortunately, I don't see how to fix this properly like you suggest. In order to construct a `WildPat` we need to know the type the wildcard is meant to be, this information is not maintained anywhere in the `ConPatOut`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:30:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:30:38 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.4727239a8c27bd11e72c6ff146450641@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I haven't a clue about STG. I just knew there was a flag about it. :) Sorry I can't be of further help here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:38:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:38:15 -0000 Subject: [GHC] #13217: configure script uses different CFLAGS from the actual build Message-ID: <047.c138ba15d723df8e3ba9a6e2304acb8d@haskell.org> #13217: configure script uses different CFLAGS from the actual build -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: autoconf | 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: -------------------------------------+------------------------------------- `configure` fails to set `CFLAGS` to the value that will actually be used. This can result in checks giving wrong results. I discovered this when working on Phab:D2996, where it led to a build failure using Clang. Note that `-Werror` cannot be used during most checks in `configure`, but is necessary for `FP_CHECK_FLAG`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:51:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:51:53 -0000 Subject: [GHC] #13217: configure script uses different CFLAGS from the actual build In-Reply-To: <047.c138ba15d723df8e3ba9a6e2304acb8d@haskell.org> References: <047.c138ba15d723df8e3ba9a6e2304acb8d@haskell.org> Message-ID: <062.01e3eee715031ef941ae446b9535095c@haskell.org> #13217: configure script uses different CFLAGS from the actual build -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: autoconf 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 rwbarton): Could you be more specific? There are various sets of flags and even potentially multiple C compilers that will be used at different points during the build of GHC. And in the instance in Phab:D2996, it looks like the failure occurred while compiling the RTS; but `-Werror` was in effect only because this was part of a validate build. More generally the user can specify additional options for building the RTS via the make variable `GhcRtsCcOpts`, and we can't know the value of that variable at configure time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 18:59:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 18:59:17 -0000 Subject: [GHC] #13218: <$ is bad in derived functor instances Message-ID: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> #13218: <$ is bad in derived functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- `Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types: {{{#!hs data Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor }}} produces {{{ Replace.$fFunctorTree_$c<$ = \ (@ a_aGl) (@ b_aGm) (eta_aGn :: a_aGl) (eta1_B1 :: Tree b_aGm) -> Replace.$fFunctorTree_$cfmap @ b_aGm @ a_aGl (\ _ [Occ=Dead] -> eta_aGn) eta1_B1 }}} Why is this bad? It fills the tree with thunks keeping the original values (which we never use again) alive. What we want to generate is {{{#!hs x <$ Bin l _ r = Bin (x <$ l) x (x <$ r) }}} When there are other functor types in the constructor, like {{{#!hs | Whatever (Tree (Tree a)) }}} we will need to insert `fmap (x <$) t`. The overall shape should be basically the same as `fmap` deriving. Note: there are some types for which we will not realistically be able to derive optimal definitions. In particular, fixed-shape, undecorated types that appear in nested types allow special treatment: {{{#!hs data Pair a = Pair a a deriving Functor data Tree2 a = Z a | S (Tree2 (Pair a)) deriving Functor }}} The ideal definition for this type is {{{#!hs x <$ Z _ = Z x x <$ S t = S (Pair x x <$ t) }}} but that requires cleverness. We should probably settle for {{{#!hs x <$ Z _ = Z x x <$ S t = S (fmap (x <$) t) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 21:22:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 21:22:52 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.b214610cbc6d0617bf1c9eab5590c66c@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I've been bitten by this bug just now. With GHC 8.0.1 this simple program will not compile because of inaccessible branches: {{{#!hs {-# LANGUAGE GADTs, StandaloneDeriving #-} module T11066 where data Foo a where A :: Foo Int B :: Foo Bool C :: Foo a -> Foo a deriving instance Eq (Foo a) deriving instance Ord (Foo a) }}} GHC complains with five identical error messages, one for each derived function of `Ord` type class (this error is for `compare`): {{{ T11066.hs:11:1: Couldn't match type ‘Bool’ with ‘Int’ Inaccessible code in a pattern with constructor A :: Foo Int, in a case alternative In the pattern: A {} In a case alternative: A {} -> GT In the expression: case b of { A {} -> GT B -> EQ _ -> LT } When typechecking the code for ‘compare’ in a derived instance for ‘Ord (Foo a)’: To see the code I am typechecking, use -ddump-deriv }}} Here's the derived code of `compare` (after some cleanup): {{{#!hs instance Ord (Foo a) where compare a b = case a of A -> case b of A -> EQ _ -> LT B -> case b of A {} -> GT B -> EQ _ -> LT C c -> case b of C d -> (c `compare` d) _ -> GT }}} It is of course possible to write a well-typed instance of `Ord`: {{{#!hs instance Ord (Foo a) where compare A A = EQ compare A _ = LT compare _ A = GT compare B B = EQ compare B (C _) = LT compare (C _) B = GT compare (C a) (C b) = compare a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 21:30:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 21:30:08 -0000 Subject: [GHC] #13218: <$ is bad in derived functor instances In-Reply-To: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> References: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> Message-ID: <060.6995e5d5dbe6086e6f8dceb1c413cbf3@haskell.org> #13218: <$ is bad in derived functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 21:33:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 21:33:44 -0000 Subject: [GHC] #13219: CSE for join points Message-ID: <049.356ff616fe8ea0d0d5220b9d68f67a02@haskell.org> #13219: CSE for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Join points are hazardous for CSE: {{{ join j = e in ... f e ... }}} The temptation is of course to rewrite to {{{ join j = e in ... f (jump j) ... }}} which doesn't typecheck because you can't have a jump in an argument. Similarly: {{{ join j x = e in let y = (... join j2 x = e in ...) in ... }}} can't be rewritten to {{{ join j x = e in let y = (... join j2 x = jump j x ...) in ... }}} because you can't jump out of a value binding. This doesn't seem to come up very often (took a long time for me to trip over it). The simple solution is simply to ignore CSE for join points. That's what we do at the moment. But this is saddening in some cases: {{{ join j x = e in join j2 x = e in ... }}} can perfectly well become {{{ join j x = e in join j2 x = jump j x in ... }}} We just need to track which join points are still currently valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 21:39:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 21:39:08 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points Message-ID: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Need to look at, among others: * `perf/compiler/T9961` * `deriving/perf/T10858` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 21:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 21:50:21 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points Message-ID: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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 clear why the warning from `OccurAnal` about rediscovering join points is ever firing. There's one circumstance I can think of, namely the special typing rule allowing jumps from β-redexes, but the warning fires repeatedly and β-redexes don't survive the simplifier. This isn't hard evidence of something wrong, but it indicates the occurrence analyzer may be missing something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 21:52:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 21:52:11 -0000 Subject: [GHC] #13222: Update formalism for join points Message-ID: <049.b34747a00c615a5f34c9610329937813@haskell.org> #13222: Update formalism for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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 rather flagrantly violated the entreaties in `CoreLint` about updating the formalism (namely by adding join points). Need to fix that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 22:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 22:04:39 -0000 Subject: [GHC] #13223: Core Prep sometimes generates case of type lambda Message-ID: <049.9e2c8408c6b249855a23e17c2dfec692@haskell.org> #13223: Core Prep sometimes generates case of type lambda -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer 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: -------------------------------------+------------------------------------- Found something odd when updating the test case for T13156: Core Prep will turn {{{ let f = \@a -> case ... in case f @ Any of ... }}} into {{{ case (\@a -> case ...) of f { __DEFAULT -> case f @ Any of ... }}} because `f` is demanded and not an HNF. Seems like this is turning a lazy binding into a strict one since that \@a is about to be erased, but I haven't investigated. (Assigning to myself to put together a proper test case at least.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 22:07:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 22:07:32 -0000 Subject: [GHC] #13224: Rules and join points Message-ID: <049.c52a15bdec4d5fc5a8588083dff104b6@haskell.org> #13224: Rules and join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | 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 Note [Rules and join points] in `OccurAnal`: Things get fiddly with rules. Suppose we have: {{{ let j :: Int -> Int j y = 2 * y k :: Int -> Int -> Int {-# RULES "SPEC k 0" k 0 = j #-} k x y = x + 2 * y in ... }}} Now suppose that both j and k appear only as saturated tail calls in the body. Thus we would like to make them both join points. The rule complicates matters, though, as its RHS has an unapplied occurrence of j. //However//, if we were to eta-expand the rule, all would be well: {{{ {-# RULES "SPEC k 0" forall a. k 0 a = j a #-} }}} So conceivably we could notice that a potential join point would have an "undersaturated" rule and account for it. This would mean we could make something that's been specialised a join point, for instance. But local bindings are rarely specialised, and being overly cautious about rules only costs us anything when, for some `j`: * Before specialisation, `j` has non-tail calls, so it can't be a join point. * During specialisation, `j` gets specialised and thus acquires rules. * Sometime afterward, the non-tail calls to `j` disappear (as dead code, say), and so now `j` //could// become a join point. This appears to be very rare in practice. TODO Perhaps we should gather statistics to be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 1 22:36:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Feb 2017 22:36:09 -0000 Subject: [GHC] #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios In-Reply-To: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> References: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> Message-ID: <065.1ba3aa0b52fa74a40c40641025981875@haskell.org> #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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:D3058 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D3058 Comment: See Phab:D3058 If you ever run into problems with interface files the best way to debug them is to use one-shot mode (`-c`) rather than make mode. This ensures that you are actually loading the interface files each time rather than caching the information between modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 00:20:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 00:20:26 -0000 Subject: [GHC] #11568: Regression in nofib/shootout/k-nucleotide In-Reply-To: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> References: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> Message-ID: <062.cbaf386663b4279ed23f8e9f764385e9@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: lukemaurer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 12988 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2853 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: dfeuer => lukemaurer * differential: => Phab:D2853 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 00:25:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 00:25:33 -0000 Subject: [GHC] #12988: Join points In-Reply-To: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> References: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> Message-ID: <064.f936c9ba91004d68362fca68f1beac8b@haskell.org> #12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2853 Wiki Page: SequentCore | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed Comment: Luke Maurer completed this in 8d5cf8bf584fd4849917c29d82dcf46ee75dd035. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:12:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:12:17 -0000 Subject: [GHC] #13225: Fannkuch-redux time regression from join point patch Message-ID: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> #13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to [https://perf.haskell.org/ghc/#revision/8d5cf8bf584fd4849917c29d82dcf46ee75dd035 Gipeda], the join point rework caused an impressive 99.9% drop in allocations in fannkuch-redux, but an 8.57% increase in its run-time. Looking at the graph, it appears that this is not just noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:17:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:17:25 -0000 Subject: [GHC] #13222: Update formalism for join points In-Reply-To: <049.b34747a00c615a5f34c9610329937813@haskell.org> References: <049.b34747a00c615a5f34c9610329937813@haskell.org> Message-ID: <064.b46e79b8f968ba6dc15bf45715e1e2b2@haskell.org> #13222: Update formalism for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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 dfeuer): * failure: None/Unknown => Other * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:25:31 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.1445dcadeea0276cbf90d07c7d96e71a@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.4.1 Comment: This does ''not'' appear to be fixed by the join point update. The second argument is still boxed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:28:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:28:17 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.38d0a87d9a7a73918202789a3b733006@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.4.1 Comment: Can you please try to provide a test case, and an explanation of why this may be a problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:33:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:33:37 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.72852a9ac3c92917c324fb6db8bc3409@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => Runtime performance bug * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:48:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:48:04 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.78756a489871feed2585d6de335eebe0@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This does not seem to be an issue for this case after applying Luke's patch either (no join point and no problem). Are there reasons to suspect this is still an issue? If so, we need a new test case; otherwise I think we can close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 01:49:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 01:49:00 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.ec7ba4d006dedfc9a35ff7a9ed030f0a@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => infoneeded * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 03:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 03:01:17 -0000 Subject: [GHC] #13222: Update formalism for join points In-Reply-To: <049.b34747a00c615a5f34c9610329937813@haskell.org> References: <049.b34747a00c615a5f34c9610329937813@haskell.org> Message-ID: <064.b47882fcdc3871167557725d46ff490a@haskell.org> #13222: Update formalism for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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): Let me know if you need assistance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 03:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 03:14:26 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch Message-ID: <045.604945792be7d5cdffc4562258697d1f@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 leads to compiler allocation regressions in T12425 and T13035 when those tests are compiled with `-O2`. I took a look at T13035 tonight. `-v` reveals more terms and types. Interestingly, it appears that virtually all the string literals arise from the derived `Typeable` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 03:17:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 03:17:37 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.dc6c5b9a416ef431f104ad0c030d0617@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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 dfeuer): It appears the strings are also for `Typeable` in T12425. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:09:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:09:58 -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.2f420ab29f6d515e285d179c1caad431@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.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: | Phab:D1795 -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high * milestone: 8.2.1 => 8.4.1 Comment: I don't believe this will get fixed for 8.2 (assuming it is indeed still a problem; I've not seen such terrible performance checking `OptCoercion`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:11:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:11:02 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.64947da720e530e082285df6744f7678@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, 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 bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This was a bit trickier than we anticipated and consequently we will be punting it to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:12:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:12:34 -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.64bdd8ccc388387e0a496c03337eae1a@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: The patches for this are essentially done. I just need to clean them up and merge them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:13:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:13:09 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.9a97cf687f86e2c97545aac9057bc451@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.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 bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't be happening for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:38:05 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.0567c73273dabb4ec2ed7748b45b9ea9@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f5b275a239d2554c4da0b7621211642bf3b10650/ghc" f5b275a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5b275a239d2554c4da0b7621211642bf3b10650" Don't tick top-level string literals This fixes a regression due to D2605 (see #8472) wherein top-level primitive strings would fail to be noticed by CoreToStg as they were wrapped in a tick. This resulted in a panic in CoreToStg due to inconsistent CAF information (or a Core Lint failure, if enabled). Here we document the invariant that unlifted expressions can only sit at top-level if of the form `Lit (MachStr ...)` with no ticks or other embellishments. Moreover, we fix instance of this in `Simplify.prepareRhs` and `FloatOut.wrapTick` where this invariant was being broken. Test Plan: Validate with `-g`. Run testsuite with `WAY=ghci`. Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, akio, scpmw, thomie Differential Revision: https://phabricator.haskell.org/D3051 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:38:05 -0000 Subject: [GHC] #13181: Introduce GHC.TypeNats module with natVal In-Reply-To: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> References: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> Message-ID: <060.1a6f7e672d01c1c7d8cbc67e81670c8a@haskell.org> #13181: Introduce GHC.TypeNats module with natVal -------------------------------------+------------------------------------- Reporter: phadej | Owner: phadej Type: feature request | Status: patch 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): Phab:D3024 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1fcede43d2b30f33b7505e25eb6b1f321be0407f/ghc" 1fcede43/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1fcede43d2b30f33b7505e25eb6b1f321be0407f" Introduce GHC.TypeNats module, change KnownNat evidence to be Natural Reviewers: dfeuer, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3024 GHC Trac Issues: #13181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:38:05 -0000 Subject: [GHC] #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios In-Reply-To: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> References: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> Message-ID: <065.c95f12db5fdb45a81d2f30054f770800@haskell.org> #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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:D3058 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b16239a95b730dd2d6fc0dbb18c8430669f2c187/ghc" b16239a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b16239a95b730dd2d6fc0dbb18c8430669f2c187" Make interface loading for COMPLETE pragmas lazy Without this additional laziness we will loop forever trying to find the definitions of the conlikes referenced in the pragma. Fixes #13188 Reviewers: austin, RyanGlScott, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3058 GHC Trac Issues: #13188 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 04:54:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 04:54:15 -0000 Subject: [GHC] #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios In-Reply-To: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> References: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> Message-ID: <065.ecad490f53137131fe62bf36b091fa4b@haskell.org> #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms 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:D3058 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 05:19:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 05:19:53 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.94158ec8a561b2007e5eb6c60e1fb1e0@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12000, #9878 | Differential Rev(s): Phab:D2504 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eedb3df0c1c28a7abc43705d614239c1c6199a1f/ghc" eedb3df0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eedb3df0c1c28a7abc43705d614239c1c6199a1f" Add support for StaticPointers in GHCi Here we add support to GHCi for StaticPointers. This process begins by adding remote GHCi messages for adding entries to the static pointer table. We then collect binders needing SPT entries after linking and send the interpreter a message adding entries with the appropriate fingerprints. Test Plan: `make test TEST=StaticPtr` Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin, hvr, erikd Reviewed By: simonpj, simonmar Subscribers: RyanGlScott, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2504 GHC Trac Issues: #12356 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 05:20:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 05:20:14 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.73990f3d3ef45a86f98eea619588c56f@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12000, #9878 | Differential Rev(s): Phab:D2504 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 05:31:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 05:31:34 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.da944ca48562af4b531bd4c0dabf4971@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed Comment: This is now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 07:48:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 07:48:39 -0000 Subject: [GHC] #11836: Hello World Bug - silent stdout errors In-Reply-To: <042.baad19c7e01cfc8c7893de62fb103b5f@haskell.org> References: <042.baad19c7e01cfc8c7893de62fb103b5f@haskell.org> Message-ID: <057.a7d1292495b8187e785fdc781e2ef21f@haskell.org> #11836: Hello World Bug - silent stdout errors -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | 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: #11180 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by siddhanathan): The first case is interesting. The following should fail as intended: {{{#!hs import System.IO main = do hSetBuffering stdout (BlockBuffering (Just 14)) putStrLn "Hello, World!" }}} {{{ $ ghc hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... $ ./hello > /dev/full ; echo $? hello: : commitBuffer: resource exhausted (No space left on device) 1 }}} But one small change can make it silently succeed: {{{#!hs import System.IO main = do hSetBuffering stdout (BlockBuffering (Just 15)) putStrLn "Hello, World!" }}} {{{ $ ghc hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... $ ./hello > /dev/full ; echo $? 0 }}} In the absence of an explicit statement for setting the buffering mode, the code might be similar to this: {{{#!hs import System.IO main = do hSetBuffering stdout (BlockBuffering Nothing) putStrLn "Hello, World!" }}} in which case, GHC may resort to using a fairly large number like `dEFAULT_CHAR_BUFFER_SIZE`. To verify that this is the case, you could try the following: {{{#!hs main = putStrLn $ replicate (1024*8) '.' }}} and now things are consistent again: {{{ $ ghc hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... $ ./hello > /dev/full ; echo $? hello: : commitBuffer: resource exhausted (No space left on device) 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 08:14:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 08:14:46 -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.fe52cd9366e93c540857814d35d9edd9@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 alexbiehl): I have put together a proof of concept [https://github.com/alexbiehl/ghc/commit/57a1a3506c90f2b8f75014ca71ca6b6730605502 here]. It supports newtypes over unlifted data *and* unlifted data types (with unpacking). This is done without much knowledge about what is a right or wrong thing to do. But I would be happy if we could discuss it and maybe make it a patch we all agree with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 08:23:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 08:23:27 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.3bcbf6bb022ade08e5e07b5b0317a55a@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | 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 siddhanathan: @@ -7,1 +7,1 @@ - flags` directives already present in the users guide. This will involve a + flag` directives already present in the users guide. This will involve a New description: Since the move to ReStructuredText and Sphinx we've generated the options summary tables and manpage with `utils/mkUserGuidePart`. The options are described in a set of Haskell modules which are a pain to edit and may easily fall out of date. It would be far better if we could generate these tables from the `.. ghc- flag` directives already present in the users guide. This will involve a bit of hacking with Sphinx, although it should be more than up to the task. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 08:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 08:30:45 -0000 Subject: [GHC] #12988: Join points In-Reply-To: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> References: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> Message-ID: <064.54d4d41e7e3b25f1969864f34c653b4a@haskell.org> #12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2853 Wiki Page: SequentCore | -------------------------------------+------------------------------------- Comment (by simonpj): PS: there are a bunch of open tickets, listed on wiki:SequentCore, but the main commit is done: {{{ commit 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 Author: Luke Maurer Date: Wed Feb 1 11:56:01 2017 -0500 Join points This major patch implements Join Points, as described in https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have to read that page, and especially the paper it links to, to understand what's going on; but it is very cool. It's Luke Maurer's work, but done in close collaboration with Simon PJ. This Phab is a squash-merge of wip/join-points branch of https://github.com/lukemaurer/ghc. There are many, many interdependent changes. Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie Differential Revision: https://phabricator.haskell.org/D2853 >--------------------------------------------------------------- 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 compiler/backpack/RnModIface.hs | 4 +- compiler/basicTypes/BasicTypes.hs | 126 ++- compiler/basicTypes/Demand.hs | 8 +- compiler/basicTypes/Id.hs | 62 +- compiler/basicTypes/IdInfo.hs | 34 +- compiler/basicTypes/IdInfo.hs-boot | 2 + compiler/basicTypes/Var.hs | 18 +- compiler/basicTypes/VarEnv.hs | 10 +- compiler/coreSyn/CoreArity.hs | 158 +++- compiler/coreSyn/CoreArity.hs-boot | 6 + compiler/coreSyn/CoreLint.hs | 337 ++++++-- compiler/coreSyn/CorePrep.hs | 120 ++- compiler/coreSyn/CoreStats.hs | 44 +- compiler/coreSyn/CoreSubst.hs | 33 +- compiler/coreSyn/CoreSyn.hs | 223 ++++- compiler/coreSyn/CoreUnfold.hs | 47 +- compiler/coreSyn/CoreUtils.hs | 19 +- compiler/coreSyn/MkCore.hs | 1 + compiler/coreSyn/PprCore.hs | 33 +- compiler/deSugar/DsUtils.hs | 14 + compiler/iface/IfaceSyn.hs | 36 +- compiler/iface/TcIface.hs | 13 +- compiler/iface/ToIface.hs | 5 + compiler/simplCore/CSE.hs | 16 +- compiler/simplCore/CoreMonad.hs | 2 + compiler/simplCore/FloatIn.hs | 79 +- compiler/simplCore/FloatOut.hs | 261 ++++-- compiler/simplCore/LiberateCase.hs | 24 +- compiler/simplCore/OccurAnal.hs | 956 ++++++++++++++++----- compiler/simplCore/SetLevels.hs | 363 ++++++-- compiler/simplCore/SimplCore.hs | 17 +- compiler/simplCore/SimplEnv.hs | 204 ++++- compiler/simplCore/SimplUtils.hs | 29 +- compiler/simplCore/Simplify.hs | 554 ++++++++---- compiler/specialise/Rules.hs | 6 +- compiler/specialise/SpecConstr.hs | 23 +- compiler/specialise/Specialise.hs | 23 +- compiler/stgSyn/CoreToStg.hs | 286 +++--- compiler/stranal/DmdAnal.hs | 16 +- compiler/stranal/WorkWrap.hs | 74 +- compiler/stranal/WwLib.hs | 96 ++- compiler/types/Type.hs | 66 ++ compiler/utils/Outputable.hs | 13 + compiler/utils/UniqFM.hs | 10 + .../tests/deSugar/should_compile/T2431.stderr | 29 +- testsuite/tests/deriving/perf/all.T | 4 +- .../tests/numeric/should_compile/T7116.stdout | 21 +- testsuite/tests/perf/compiler/all.T | 18 +- testsuite/tests/perf/haddock/all.T | 6 +- .../should_compile => perf/join_points}/Makefile | 0 testsuite/tests/perf/join_points/all.T | 28 + testsuite/tests/perf/join_points/join001.hs | 16 + testsuite/tests/perf/join_points/join002.hs | 51 ++ .../tests/perf/join_points/join002.stdout | 0 testsuite/tests/perf/join_points/join003.hs | 69 ++ .../tests/perf/join_points/join003.stdout | 0 testsuite/tests/perf/join_points/join004.hs | 30 + testsuite/tests/perf/join_points/join004.stdout | 1 + testsuite/tests/perf/join_points/join005.hs | 23 + testsuite/tests/perf/join_points/join006.hs | 22 + testsuite/tests/perf/join_points/join007.hs | 42 + testsuite/tests/perf/join_points/join007.stdout | 1 + testsuite/tests/perf/should_run/all.T | 6 +- .../tests/roles/should_compile/Roles13.stderr | 41 +- testsuite/tests/simplCore/should_compile/Makefile | 3 +- testsuite/tests/simplCore/should_compile/T13156.hs | 37 +- .../tests/simplCore/should_compile/T13156.stdout | 4 +- .../tests/simplCore/should_compile/T3717.stderr | 17 +- .../tests/simplCore/should_compile/T3772.stdout | 17 +- .../tests/simplCore/should_compile/T4908.stderr | 19 +- .../tests/simplCore/should_compile/T4930.stderr | 28 +- .../tests/simplCore/should_compile/T5658b.stdout | 2 +- .../tests/simplCore/should_compile/T7360.stderr | 47 +- .../tests/simplCore/should_compile/T9400.stderr | 15 +- testsuite/tests/simplCore/should_compile/all.T | 3 +- .../tests/simplCore/should_compile/par01.stderr | 15 +- .../simplCore/should_compile/spec-inline.stderr | 29 +- 77 files changed, 3964 insertions(+), 1151 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:01:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:01:09 -0000 Subject: [GHC] #13225: Fannkuch-redux time regression from join point patch In-Reply-To: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> References: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> Message-ID: <060.cc25024813496d39019660d113ad7365@haskell.org> #13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > join point rework caused an impressive 99.9% drop in allocations in fannkuch-redux, but an 8.57% increase in its run-time That's is truly weird. It'd be good to understand why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:03:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:03:17 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.17e95091a305c9dff7703e0451fa69f4@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The second argument is still boxed Even with -O2 (which does a second demand/absence analysis pass? I think, though I have not dug into it, that the absence may only show up late. Even if that's true, we should just check to ensure that there's no way it could have been caught in the first pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:14:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:14:59 -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.f68fc6cf9e68697fc273bfbe6263cfa3@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): > I would really like a wiki page to describe the design, please. Maybe it's a simple page -- if so, so much the better. Alex, it's great that you have made a patch but I can't even begin to look at it until I know precisely what it is intended to achieve. Specification before implementation. You might also (perhaps in parallel) want to formulate a [https://github.com/ghc-proposals/ghc-proposals GHC Proposal]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:22:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:22:11 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.5d7ed0099223bae45b09a8d69b9a115e@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -1,1 +1,2 @@ - Need to look at, among others: + Need to look at some modest performance regressions for the main join- + point patch (#12988, wiki [wiki:SequentCore]): @@ -3,2 +4,4 @@ - * `perf/compiler/T9961` - * `deriving/perf/T10858` + * `perf/compiler/T9961`: `bytes_allocated` + * `perf/compiler/T10356`: `bytes_allocated` + * `perf/compiler/T1969`: `max_bytes_used` + * `deriving/perf/T10858`: `bytes_allocated` New description: Need to look at some modest performance regressions for the main join- point patch (#12988, wiki [wiki:SequentCore]): * `perf/compiler/T9961`: `bytes_allocated` * `perf/compiler/T10356`: `bytes_allocated` * `perf/compiler/T1969`: `max_bytes_used` * `deriving/perf/T10858`: `bytes_allocated` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:38:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:38:26 -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.910bb92e060e501321117e68a331a975@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 alexbiehl): I'm sorry, I falsely implied the context of this thread. I think the general idea is described in https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes. I noticed the conversation here got stalled so I picked up and experimented where osa1 left: https://ghc.haskell.org/trac/ghc/ticket/1311#comment:12 describes a construct like the following: {{{ type Unlifted = TYPE 'UnliftedRep newtype Blah :: TYPE 'IntRep where Blah :: Int# -> Blah data T :: Unlifted where T :: Int -> Int -> T }}} Which allows: 1. newtype declaration over unlifted types 2. data declarations which are represented through an unlifted pointer (do not contain bottom) The approach mentioned on `UnliftedDataTypes` page introduces a new keyword `unlifted`. This approach differs in that we give the unlifted representation through an explicit kind signature on the newtype/data type instead of a new syntax. And that is what the patch allows in https://ghc.haskell.org/trac/ghc/ticket/1311#comment:18 enables us to write. I can formulate a proposal next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:48:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:48:16 -0000 Subject: [GHC] #13223: Core Prep sometimes generates case of type lambda In-Reply-To: <049.9e2c8408c6b249855a23e17c2dfec692@haskell.org> References: <049.9e2c8408c6b249855a23e17c2dfec692@haskell.org> Message-ID: <064.48b919ee797677cc30efe6d9382d6f99@haskell.org> #13223: Core Prep sometimes generates case of type lambda -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer 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): What is the actual problem here? It looks ok to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:50:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:50:19 -0000 Subject: [GHC] #13224: Rules and join points In-Reply-To: <049.c52a15bdec4d5fc5a8588083dff104b6@haskell.org> References: <049.c52a15bdec4d5fc5a8588083dff104b6@haskell.org> Message-ID: <064.a6cf8604aa1fd0780c4a7cd00191b9e9@haskell.org> #13224: Rules and join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In the case where `j` is a join-point ''before'' specialisation, are we sure it'll stay a join-point afterwards? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 09:55:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 09:55:07 -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.fd96b5754f979ddc82f0bbb9f346b3eb@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): I'll look forward to the proposal. It's a remarkably small patch! Don't forget to add comprehensive tests etc. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 11:04:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 11:04:34 -0000 Subject: [GHC] #13212: Support abs as a primitive operation on floating point numbers. In-Reply-To: <046.0fa5a9a408d7a4d76cfff2dd4c5e7b6b@haskell.org> References: <046.0fa5a9a408d7a4d76cfff2dd4c5e7b6b@haskell.org> Message-ID: <061.cda8f02022ac429b15155e8c18da9a72@haskell.org> #13212: Support abs as a primitive operation on floating point numbers. -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): I have this working. I am not sure what sort of test to put in. Maybe just keep the current one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 12:11:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 12:11:41 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB Message-ID: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I've just discovered this {{{ g4 x expensive ys = let h = \7 -> y + expensive x in map h ys }}} Of course we'd expect the `(expensive x)` call to be floated out of the `\y`-abstraction, so that it is only done once. But it isn't! Here's the simplified core with -O: {{{ g4 = \ (@ b_aPG) (@ p_atr) ($dNum_aPP :: Num b) (x_arW :: p) (expensive_arX :: p -> b) (ys_arY :: [b]) -> map @ b @ b (\ (y_as0 [OS=ProbOneShot] :: b) -> + @ b $dNum_aPP y_as0 (expensive_arX x_arW)) ys_arY }}} Yikes! What is happening? Answer: look at that suspicious `ProbOneShot` on the `\y` above. Read `Note [Computing one-shot info, and ProbOneShot]` in `Demand.hs`. When `FloatOut` runs we have {{{ g4 = \ (@ b_aPL) (@ p_atw) ($dNum_aPU :: Num b) (x_as1 :: p) (expensive_as2 :: p -> b) (ys_as3 :: [b]) -> GHC.Base.build @ b (\ (@ b1_aQs) (c_aQt [OS=OneShot] :: b -> b1 -> b1) (n_aQu [OS=OneShot] :: b1) -> GHC.Base.foldr @ b @ b1 (GHC.Base.mapFB @ b @ b1 @ b c_aQt (\ (y_as5 [OS=ProbOneShot] :: b) -> + @ b $dNum_aPU y_as5 (expensive_as2 x_as1))) n_aQu ys_as3) }}} Why is the `\y` marked `ProbOneShot`? Because the occurrence analyser marked it so, based on the cardinality info from `mapFB`, even though `mapFB` was not saturated. So `Demand.argsOneShots` makes a deliberate choice to play risky, and that choice backfires badly for use of `map`. Not good! The offending commit, which introduced this behaviour, is (I think) {{{ commit 80989de947dc7edb55999456d1c1e8c337efc951 Author: Simon Peyton Jones Date: Fri Nov 22 17:13:05 2013 +0000 Improve the handling of used-once stuff Joachim and I are committing this onto a branch so that we can share it, but we expect to do a bit more work before merging it onto head. Nofib staus: - Most programs, no change - A few improve - A couple get worse (cacheprof, tak, rfib) Investigating the "get worse" set is what's holding up putting this on head. The major issue is this. Consider map (f g) ys where f's demand signature looks like f :: -> -> . So 'f' is not saturated. What demand do we place on g? Answer C(C1(U)) That is, the inner C1 should stay, even though f is not saturated. I found that this made a significant difference in the demand signatures inferred in GHC.IO, which uses lots of higher-order exception handlers. I also had to add used-once demand signatures for some of the 'catch' primops, so that we know their handlers are only called once. }}} The commit isn't explicit about exactly what the "significant differences" are. Moreover note that in the comment the outer C1 is replaced by C, but nothing like that seems to happen in the code. This needs investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 16:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 16:04:10 -0000 Subject: [GHC] #13225: Fannkuch-redux time regression from join point patch In-Reply-To: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> References: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> Message-ID: <060.6a2b09b6842821d0688e767cf1833d5d@haskell.org> #13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 16:28:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 16:28:06 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.e652920b9935e790deb170250ad5e8b2@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 16:54:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 16:54:19 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.2fab39144bbad536364876c3f531c114@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): That reminds me of a question that I had a long time: What is the precise semantics of `ProbOneShot`? I only understand `OneShot`… I read `Note [Computing one-shot info, and ProbOneShot]` and it seems that the compiler is acting according to plan (marking this partial application as `ProbOneShot`, and then not floating the expression out). Are you saying that the plan as described in the note might be bogus, or is the implementation not doing what it should? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 16:56:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 16:56:31 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.83687a0f41e15e5734d300fffbf5b38b@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm saying that the plan is counter-productive in this case. Step 1: remove `ProbOneShot` and see what, if anything, gets worse. It's a very local change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 17:05:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 17:05:32 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.f0b0ba4c89b4c2182cc7a983b9738773@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"d8ac64e782b8543e5a525c7bb738620bd09aa398/ghc" d8ac64e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8ac64e782b8543e5a525c7bb738620bd09aa398" Add a testcase for #13227 where an expected float-out is not happening. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 17:10:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 17:10:06 -0000 Subject: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions In-Reply-To: <043.be417919ffcce10010ccb473704f0755@haskell.org> References: <043.be417919ffcce10010ccb473704f0755@haskell.org> Message-ID: <058.983892b05e47e855fc4233e188341697@haskell.org> #2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double 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): Replying to [comment:16 thomie]: > But `testWord` is still 3 times slower than `testInt`. > {{{ > $ time ./testWord > 5.00000005e15 > > real 0m0.579s > user 0m0.575s > sys 0m0.003s > > $ time ./testInt > 5.00000005e15 > > real 0m0.196s > user 0m0.191s > sys 0m0.004s > }}} > > As I can not easily explain this difference, I'll leave this ticket open for now. It's because the x86 NCG implements the new `MO_UF_Conv` as a call to a C function, rather than generating code inline like `MO_SF_Conv` (`cvtsi2sdq`). Unfortunately there's no corresponding instruction for converting an unsigned 64-bit integer to float or double, but for converting to double the code generated by `clang -O` is pretty small and simple and probably worth inlining. It will still be somewhat slower than `Int` though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 17:19:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 17:19:10 -0000 Subject: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions In-Reply-To: <043.be417919ffcce10010ccb473704f0755@haskell.org> References: <043.be417919ffcce10010ccb473704f0755@haskell.org> Message-ID: <058.f274337bc95f44b95bf5d46cad3f4f7f@haskell.org> #2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double, newcomer 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 rwbarton): * keywords: rules, performance, double => rules, performance, double, newcomer Comment: Namely, {{{ double f(unsigned long x) { return x; } /* 0000000000000000 : 0: 66 48 0f 6e cf movq %rdi,%xmm1 5: 66 0f 62 0d 00 00 00 punpckldq 0x0(%rip),%xmm1 # d c: 00 9: R_X86_64_PC32 .LCPI0_0-0x4 d: 66 0f 5c 0d 00 00 00 subpd 0x0(%rip),%xmm1 # 15 14: 00 11: R_X86_64_PC32 .LCPI0_1-0x4 15: 66 0f 70 c1 4e pshufd $0x4e,%xmm1,%xmm0 1a: 66 0f 58 c1 addpd %xmm1,%xmm0 1e: c3 retq */ }}} Compiling the test program here with LLVM there's no measurable difference between the int and word versions, so I guess doing this is worthwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 17:54:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 17:54:38 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.ba0d59d4b2d20140ab718b07e3b8e3b2@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Step 1 happening on branch `wip/T13227`. Let’s see what perf.haskell.org will have to say on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 19:15:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 19:15:01 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.8c5ead5c881d1ea6ee465aff91431c3a@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, #12162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zyla): I think that using the promoted `Char` datatype is a good idea. I wouldn't however put in all the related type families (`ToUpper`, `IsAlpha` etc). I think it's better to provide type families for converting between `Char` and `Nat`, and let the user implement the needed functions at type level if desired. The motivation is having less code in the compiler. To sum up, my proposal is to have: 1. Promoted `Char` datatype (already there) 2. Character literal syntax in types 3. Type famililes for analyzing/constructing `Symbol`s: {{{ -- 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 }}} 4. Type families for converting between `Nat` and `Char`: {{{ type family CharToNat (c :: Char) :: Nat type familt NatToChar (n :: Nat) :: Char }}} @alexvieth: Are you planning to work on this? If not, would you mind if I took your patch, implemented the changes mentioned above and posted it to Phab? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 19:58:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 19:58:05 -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.d4a40c9164a0b38deb0336f86defd471@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch 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, #11806 | Differential Rev(s): Phab:D2105 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b10353216f5ff5d5e410334e4c118b6695b628d0/ghc" b103532/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b10353216f5ff5d5e410334e4c118b6695b628d0" Exhaustiveness check for EmptyCase (Trac #10746) Empty case expressions have strict semantics so the problem boils down to inhabitation checking for the type of the scrutinee. 3 main functions added: - pmTopNormaliseType_maybe for the normalisation of the scrutinee type - inhabitationCandidates for generating the possible patterns of the appropriate type - checkEmptyCase' to filter out the candidates that give rise to unsatisfiable constraints. See Note [Checking EmptyCase Expressions] in Check and Note [Type normalisation for EmptyCase] in FamInstEnv Test Plan: validate Reviewers: simonpj, goldfire, dfeuer, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2105 GHC Trac Issues: #10746 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 20:02:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 20:02:57 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.9e1cd4122ce8e3239f5d264b86a7cc9d@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, #12162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexvieth): Replying to [comment:9 zyla]: > @alexvieth: Are you planning to work on this? If not, would you mind if I took your patch, implemented the changes mentioned above and posted it to Phab? (with appropriate credits of course) Go for it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 20:06:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 20:06:46 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.37d6f6e25e7ff898312269b609d61b54@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm actually not sure that the effect on the whole is all that modest, unfortunately. [[https://perf.haskell.org/ghc/#revision/8d5cf8bf584fd4849917c29d82dcf46ee75dd035|Gipeda]] shows that the build time for GHC itself went up by 13%. While some increase is to be expected, this is quite significant. Are there any obvious knobs that could be adjusted to reduce the amount of work that the join point analysis/simplifier do under `-O1`? The full analysis is great for `-O2`, but I do fear that users will be up in arms if the GHC regression is representative of user code. Also, strangely enough, while the join points work eliminated all allocations from `fannkuch-redux`, the actual runtime of this test might have actually gone up by 8%. I say "might have" since runtime measurements are notoriously unstable, but it does look likely that this is a real regression: the test's runtime is quite long (4 seconds) and 8% is quite a large change. Even if this measurement were off by a factor of two we would want to understand it. Can you shed any light on this, Luke? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 20:44:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 20:44:55 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.b79f56f3b1ed4018111b2f0c7f42da1e@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): The `fannkuch-redux` weirdness is tracked at #13225. And it is stable: Once a few more commits come in, one can clearly distinguish a regression from a occasional one-time bump (that occur with some tests), and this is one: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 20:48:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 20:48:51 -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.ff2b593a91b71d62becb1f16c86efbc9@haskell.org> #10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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, #11806 | Differential Rev(s): Phab:D2105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 20:51:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 20:51:58 -0000 Subject: [GHC] #12396: Panic when specializing in another module In-Reply-To: <047.cfbab0d2aaad50ebf39c103bee8948e0@haskell.org> References: <047.cfbab0d2aaad50ebf39c103bee8948e0@haskell.org> Message-ID: <062.51187ff26cbb5e2673bd35e4c11ac740@haskell.org> #12396: Panic when specializing in another module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 zyla): On `HEAD` (`8.1.20170202`) this doesn't cause a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 20:56:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 20:56:21 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.20224200fe356b3efa54d6f37934b97a@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 21:00:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 21:00:08 -0000 Subject: [GHC] #13098: Template Haskell support for Pattern Synonym's Complete Pragma In-Reply-To: <047.5c7bf2bbd6e375ea42b9abcc915a892d@haskell.org> References: <047.5c7bf2bbd6e375ea42b9abcc915a892d@haskell.org> Message-ID: <062.3fda050bd21d0098b268b1ab95f4fea6@haskell.org> #13098: Template Haskell support for Pattern Synonym's Complete Pragma -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 21:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 21:17:54 -0000 Subject: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched In-Reply-To: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> References: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> Message-ID: <057.45e21fbd7d989a317ff7c4c3860d5269@haskell.org> #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: warnings 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 mpickering): I think this is out of scope of the pattern match checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 21:59:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 21:59:57 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.b7d33dd757d4c1e556759cb8b0a00143@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #11179 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #11179 Comment: This might be a solution to #11179. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 22:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 22:00:27 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.c668c540df1a4a23031f658343ecfcfc@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | 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: #10823 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #10823 Comment: #10823 refers to the same issue (which I just stumbled over myself). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 22:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 22:04:08 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.550a388b5fa9ce780340b8318815a35e@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | 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 nomeata): * related: #10823 => Comment: I have his this problem as well now. I don’t like any solution that requires unwieldy interaction from the user. That leaves * not removing dead code in the desugarer or * adding a hook to the plugins interface to interact with the code before desugaring (and maybe mark bindings as “please keep”) While the second one would surely be useful for many other things, I wonder why we not simply do the first one. We remove dead code later anyways (do we?), and the extra cost of desugaring dead code seems to be neglectible, as there usually is no dead code. (And if there is, then most likely for a good reason – e.g. to be picked up by plugins). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 22:16:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 22:16:18 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.442235130928c49a5444cbeaa85d1c91@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | 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 gridaphobe): I looked into this briefly a while ago, and IIRC the first option may be as simple as removing the call to `simpleOptPgm` inside `Desugar.deSugar`. Or, rather, moving it to an initial Core2Core pass, which would preserve the current pipeline but cleanly allow plugins access to the fully unoptimized program. There's a warning right before the call though, that suggests the unoptimized program may be excessively large. I don't know how much of a concern this would be in practice. The other thing to consider is whether removing the initial optimization pass may break existing Core2Core plugins. If a plugin inserts itself at the beginning of the Core2Core pipeline, the overall order would change from {{{ simpleOptPgm > plugin > ... }}} to {{{ plugin > simpleOptPgm > ... }}} For some plugins, e.g. Levent's or LiquidHaskell, this is exactly what is desired, but it could break others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 22:22:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 22:22:49 -0000 Subject: [GHC] #13225: Fannkuch-redux time regression from join point patch In-Reply-To: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> References: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> Message-ID: <060.236324c83312c4aa6ea512069ad32bb2@haskell.org> #13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 22:50:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 22:50:50 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.815d25f949a69fd1c13c569ab45d2b2a@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3065, Wiki Page: | Phab:D3064 -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D3065, Phab:D3064 Comment: There was actually a bug in the PM checker which was causing this bug to show up. Here is a simpler reproduction. Essentially the checker was seeing that `[]` was not consistent with `(_:_)` and thus for any nested pattern matches the initial uncovered set was empty which caused all patterns to be reported as redundant. {{{ module T12957 where data A = N | A { b :: Bool } f = case [] of (_:_) -> case () of a -> undefined }}} However, it was also good to add the case to `matchSeparator` as these matches are printed when `-ddump-ec-trace` is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 23:14:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 23:14:08 -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.c8e70fe0cd449780c38f86d4b631b10d@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11337, #11353 | Differential Rev(s): Phab:D2743 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * differential: => Phab:D2743 * resolution: => invalid Comment: It turns out that this actually isn't a problem. I don't recall what my original reasoning here was, but there seems to be no reason why we can't rely on the value of the STG `Sp` register in the vicinity of a safe foreign call. My DWARF patches work fine, even without Phab:D2743. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 23:34:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 23:34:08 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.219df4eea558059e90956d130e51f709@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Gipeda shows that the build time for GHC itself went up by 13% Well that is new and very unwelcome information. Some of the `compiler/perf` tests went down quite a bit, a couple increased. So I was under the impression that compile time impact was slight, and some runtime improvements were jolly big. But a 13% increase across the entire build is massive. Can we get any insight into what is increasing? It's hard to konw where to start with a single number across the entire build. A good place to look might be binary sizes: if we generate more code then that'll take longer to compile. Bother. Still, there is no good reason that any of this join point stuff should cost much more. Yes, the occurrence analyser is doing a bit more work, but not much. If occ-anal cost 13% more I'd be surprised. But it'd have to cost 100% more to make the entire build take 13% more. Something is fishy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 23:45:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 23:45:00 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.5008e8f96bda1408162781852c505077@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => nomeata Comment: Great, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 2 23:51:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Feb 2017 23:51:05 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.9587f695ee5d7fb718a6c2ad1dd025de@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | 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): Rather than mess with `simpleOptPgm` I think it might be better just to ask the occurrence analyser (which `simplOptPgm` uses) not to drop dead code, at least not at top level. Tha can't be hard. Just pass a boolean into `occAnalBind`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 00:32:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 00:32:40 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.0369d15fe29964a2bb379542d7e32b8a@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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 dfeuer): I've spent a bit more time looking at T212425. A couple things I've noticed: One reason we're getting more terms and types is pretty obvious. Where we used to have {{{#!hs lvl3_r2p3 = unpackCString# "T12425.hs"# }}} we now have {{{#!hs lvl6_r2GO = "T12425.hs"# lvl7_r2GP = unpackCString# lvl6_r2GO }}} Another reason is less obvious. We've always had multiple copies of some strings, but now we're getting ''more'' repeats. I don't know why that is. I also don't really if any of this is actually responsible for the allocation change, but it could be responsible for some of it. It looks like there are more terms, types and allocations for every stage past parsing, but float out is (unsurprisingly) prominent. My big question is why we're allowing these literals to be duplicated in the first place. I would think, naively perhaps, that we could assign each of them a unique, top-level identity from the start, and merely mark use- sites as inline or not, rather than actually inlining. When floating out, we could merge any two bindings in the same scope that refer to the same string identity. Those top-level identities would ultimately be resolved as either "inline-only" (not appearing in any unfoldings, etc., so they can be discarded) or otherwise. Of course we'd need to deal with the fact that built-in rules and such may be able to produce new literals, but I would think that relatively straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 00:33:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 00:33:51 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.732b0e7154bdc23cfd9c0e7c12bc7082@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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 dfeuer): Sorry, I meant T12425! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 01:27:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 01:27:21 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.2a7e40e51827c588a56647b831d2a983@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Looks like a clear win. According to perf.haskell.org (which does run nofib!), the only significant changes are time improvements of 3.5% for cacheprof and k-nucleotide: https://perf.haskell.org/ghc/#revision/4c5af213a9fff60ca8de2ed9f5ae28955d21beb6 These might be spurious, as allocations do not change. But even if really nothing changes, as this is a simplifying commit, from this point of view there is no reason not do it. And I’d be happy to get rid of this rather squishy notion of “probably” one-shot. I will prepare a DR for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 03:01:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 03:01:25 -0000 Subject: [GHC] #13228: Surprising inlining failure Message-ID: <045.29d68faa9959aafef993e95f12e59932@haskell.org> #13228: Surprising inlining failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- When I fail to mark something seemingly unrelated `INLINE`, something else doesn't inline. In the below (cut down dramatically from my recent lazy ST work), if I don't mark `>>` inline in the `Monad` instance, then `*>` never inlines, and none of the rules fire when compiling `foom` and `basic`. If `>>` is marked inline, then everything works as expected. {{{#!hs module RulesLazy (ST, strictToLazyST, lazyToStrictST) where import qualified Control.Monad.ST as ST -- No, this is not really lazy ST newtype ST s a = ST (s -> (a, s)) instance Functor (ST s) where fmap _ _ = undefined instance Applicative (ST s) where pure _ = undefined _ <*> _ = undefined m *> n = m `thenST` n {-# NOINLINE [1] thenST #-} thenST :: ST s a -> ST s b -> ST s b _ `thenST` _ = ST $ \_ -> undefined instance Monad (ST s) where {-# INLINE (>>) #-} -- CRITICAL LINE m >> n = m `thenST` n _ >>= _ = undefined {-# NOINLINE [1] strictToLazyST #-} strictToLazyST :: ST.ST s a -> ST s a strictToLazyST _ = ST $ \_ -> undefined {-# NOINLINE [1] lazyToStrictST #-} lazyToStrictST :: ST s a -> ST.ST s a lazyToStrictST _ = undefined {-# RULES "then/S2L" forall m n . m `thenST` strictToLazyST n = strictToLazyST (lazyToStrictST m *> n) "L2S/S2L" forall m . lazyToStrictST (strictToLazyST m) = m #-} module RulesBurn where import RulesLazy import qualified Control.Monad.ST as SST {-# NOINLINE foom #-} foom :: SST.ST s a -> SST.ST s b -> SST.ST s c -> ST s c foom m n o = (strictToLazyST m *> strictToLazyST n) *> strictToLazyST o {-# NOINLINE basic #-} basic :: ST s a -> SST.ST s b -> ST s b basic m n = m *> strictToLazyST n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 03:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 03:04:45 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.c389d6220d26468d81862ee5988f1096@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3067 Comment: DR at Phab:D3067 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 03:05:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 03:05:38 -0000 Subject: [GHC] #13228: Surprising inlining failure In-Reply-To: <045.29d68faa9959aafef993e95f12e59932@haskell.org> References: <045.29d68faa9959aafef993e95f12e59932@haskell.org> Message-ID: <060.189b227c50e379fc54ac2d12055efe5f@haskell.org> #13228: Surprising inlining failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: Argh! It looks like this is actually fixed in HEAD! Oops. Went down a rabbit hole of minimizing the example for nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 03:14:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 03:14:01 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.15eed5a4554b8ba3f1642731e027d5f1@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.4.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:D2839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bbd3c399939311ec3e308721ab87ca6b9443f358/ghc" bbd3c39/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbd3c399939311ec3e308721ab87ca6b9443f358" Ditch static flags This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 03:14:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 03:14:58 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.7cfeed8408773e9d7ad44c506de8e070@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.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:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: It's finally done! Thanks hsyl20! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 10:02:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 10:02:13 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.7359b1bdb1d5ef669e8a0a1c1cba9a25@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Joachim, I have resurrected from my hind-brain what was, perhaps, the original issue. Consider something like {{{ recover (f (\x. blah)) bloo }}} where `recover` :: (Exception -> IO a) -> IO a -> IO a` is some kind of exception handling. And `f` is something like {{{ f :: (Exception -> a) -> Exception -> IO a f g exn = return (g exn) }}} Now, is the `\x` one-shot or not? Well, if `f` is applied to three args (the exception and the state token, then it'll call `g` exactly once`, so yes the `\x` will be one shot. And hence there is no point floating a thunk out of `blah`. Indeed doing so is positively harmful because it adds allocation before calling `recover`, and that allocation is only used on the cold (exception-handling) path. And yet with your change, we won't recognise that, because the call to `f` is not syntactically saturated. Moreover, the occurrence analyser is the '''only''' place where one-shot info is added to lambdas. See your patch in #11770. (I'd like this fact to be more clearly called out... I had to re-discover it today. It is stated in `Note [Use one-shot information]` but not very loudly.) So we might ask 1. Does this matter? Does it actually occur in practice? Your measurements suggest not. 2. Would be easy to fix? I think it might be. Concerning (2), look at the call to `argsOneShots` in `occAnalApp`. We pass `n_val_args` to `argsOneShots`. Consider something like {{{ f (g (\y.e)) }}} and suppose * `f` has a strictness sigature like `C1(L)`, saying that it calls its argument at most once * `g` has a strictness signature like `C1(L)L`, saying that when applied to two args it calls its first arg at most once. Then when we are doing `occAnalApp` for `g (\y.e)` we will have `[NoOneShot]` in the `occ_one_shots` field of `OccEnv`... that comes from `f` which guarantees to call its arg once. So I think we can just add the length of `occ_one_shots` to `n_val_args` before passing to `argsOneShots`. And that is so easy it'd be worth doing. Here's a concrete test case {{{ w :: (Int -> a) -> a w g = g 1 {-# NOINLINE w #-} f :: (Int -> Bool) -> a -> [Bool] f g _ = [g 1, True, False] {-# NOINLINE f #-} h xs = w (f (\y -> null (reverse xs))) }}} You'll see that `null (reverse xs)` is floated out -- and it should not be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 10:20:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 10:20:48 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.86f7a8c30a457459e48dc09aac827ed5@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3065, Wiki Page: | Phab:D3064 -------------------------------------+------------------------------------- Comment (by mpickering): Actually, there are two different problems here the original report is different from the case that ocharles reported and I fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 10:30:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 10:30:17 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.5b394be4c98b47e6cec0c5b4c345f973@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 10:47:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 10:47:10 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.2e013826cfa97744c75dfefa81b2b168@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * milestone: 8.4.1 => 8.2.1 @@ -1,2 +1,15 @@ - Not clear why the warning from `OccurAnal` about rediscovering join points - is ever firing. There's one circumstance I can think of, namely the + Ben writes: I've noticed that a new WARN in OccurAnal seems to be quite + loud. Validations now produce thousands of lines of the form, + {{{ + WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 + OccurAnal failed to rediscover join point(s): [$j_shTG] + WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 + OccurAnal failed to rediscover join point(s): [$w$j_sl22] + WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 + OccurAnal failed to rediscover join point(s): [$w$j_sl1W] + WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 + OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] + }}} + + It is not clear why the warning from `OccurAnal` about rediscovering join + points is ever firing. There's one circumstance I can think of, namely the @@ -6,2 +19,1 @@ - This isn't hard evidence of something wrong, but it indicates the - occurrence analyzer may be missing something. + This isn't hard evidence of something wrong, but it is deeply suspicious. New description: Ben writes: I've noticed that a new WARN in OccurAnal seems to be quite loud. Validations now produce thousands of lines of the form, {{{ WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$j_shTG] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl22] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1W] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] }}} It is not clear why the warning from `OccurAnal` about rediscovering join points is ever firing. There's one circumstance I can think of, namely the special typing rule allowing jumps from β-redexes, but the warning fires repeatedly and β-redexes don't survive the simplifier. This isn't hard evidence of something wrong, but it is deeply suspicious. -- Comment: Let's at least investigate before releasing 8.2. It's extremely fishy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 10:51:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 10:51:44 -0000 Subject: [GHC] #13226: Compiler allocation regressions from top-level string literal patch In-Reply-To: <045.604945792be7d5cdffc4562258697d1f@haskell.org> References: <045.604945792be7d5cdffc4562258697d1f@haskell.org> Message-ID: <060.d7646479de72b683f62a2f17714361d4@haskell.org> #13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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 simonpj): > My big question is why we're allowing these literals to be duplicated in the first place Good question. Can you show a repro case, please? Returning to your first point, the extra binding is reasonable. After all, if we had {{{ x = f "foo#" y = g "foo#" }}} we might expect CSE to share those literals, and floating them to the top does just that. Moreover the final code is the same either way. But if `f` and `g` were identical (say `unpackCString#`) then we'd CSE `x` and `y` anyway. So we could choose not to float string literals unless they escaped a lambda. That would be easy to do if we wanted to try it. (We want to take them out of lambdas to allow the lambda to be inlined without duplicating the string.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 11:14:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 11:14:27 -0000 Subject: [GHC] #13186: Change EvNum to EvNum :: Natural -> EvLit In-Reply-To: <045.e9472df3c9da56f1cd7efedf1a6ea89f@haskell.org> References: <045.e9472df3c9da56f1cd7efedf1a6ea89f@haskell.org> Message-ID: <060.c4e47575bed67201ba7de2e3c003fdd1@haskell.org> #13186: Change EvNum to EvNum :: Natural -> EvLit -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8306 #8412 | Differential Rev(s): #13181 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Currently we can get: {{{ Prelude> :set -XDataKinds -XNegativeLiterals Prelude> :m +Data.Proxy Prelude Data.Proxy> Proxy :: Proxy (-1) }}} Even this case could (and should?) be ruled out in parser, thru `template- haskell` you can still inject negative integers. Thus the workaround fix is currently in the renamer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 11:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 11:28:30 -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.3b067db7eb6f58af47557640587d93cd@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is respoinding to [https://phabricator.haskell.org/D2961#inline-25611], concerning the way to use implication constraints to simplify the `DeriveAnyClass` implementation. The original idea is in [https://phabricator.haskell.org/D2961#inline-25543], where I said: I think it would help to explain more carefully what is happening here. How come we don't need to look at the data constructors any more? Example: {{{ class Foo a where bar :: Ix b => a -> b -> String default bar :: (Show a, Ix b) => a -> b -> String bar x y = show x baz :: Eq a => a -> a -> Bool default baz :: (Ord a, Show a) => a -> a -> Bool baz x y = compare x y == EQ }}} Given {{{ deriving instance Foo (Maybe d) }}} we behave as if you had written {{{ instance ??? => Foo (Maybe d) where {} }}} (that is, using the default methods from the class decl), and that in turn means {{{ instance ??? => Foo (Maybe d) where bar = $gdm_bar baz = $gdm_baz }}} where {{{ $gdm_bar :: forall a. Foo a => forall b. (Show a, Ix b) => a -> b -> String }}} is the generic default method defined by the class declaratation. Our task is to figure out what "???" should be. Answer: enough constraints to satisfy the Wanteds arising from the calls of $gdm_bar and $gdm_baz. So we end up with two sets of constraints to simplify: {{{ bar: (Givens: [Ix b], Wanteds: [Show (Maybe d), Ix b]) baz: (Givens: [Eq (Maybe d)], Wanteds: [Ord (Maybe d), Show (Maybe d)]) }}} Important: note that * the Givens come from the ordinary method type, while * the Wanteds come from the generic method. These are just implication constraints. We can combine them into a single constraint: {{{ (forall b. Ix b => Show (Maybe d), Ix b) /\ (forall . Eq (Maybe d) => Ord (Maybe d), Show (Maybe d)) }}} Notice that the type variables from the head of the instance decl (just `d` in this case) are global to this constraint, but any local quantification of the generic default method (e.g. `b` in the case of `bar`) are locally scoped to each implication, as they obviously should be. Now we solve this constraint, getting the residual constraint (RC) {{{ (forall b. Ix b => Show d) /\ (forall . Eq (Maybe b) => Ord d, Show d) }}} Now we need to hoist those constraints out of the implications to become our candidates for the "???". That is done by `approximateWC`, which will return {{{ (Show d, Ord d, Show d) }}} Now we can use `mkMinimalBySCs` to remove superclasses and duplicates, giving {{{ (Show d, Ord d) }}} And that's what we need for the "???". -------------- But we aren't done yet! Suppose we had written {{{ bar :: a -> b -> String default bar :: (Show a, C a b) => a -> b -> String }}} I've replaced `Ix b` by `C b` and I've removed it from the vanilla sig for `Bar`. Now the implication constraint will be {{{ forall b. () => Show (Maybe d), C (Maybe d) b }}} Suppose we have `instance Read p => C (Maybe p) q`. Then after simplification, we get the residual constraint (RC): {{{ forall b. () => (Show d, Read d) }}} and all is well. But suppose we had no such instance, or we had an instance like `instance C p q => C (Maybe p) q`. Then we'd finish up with the residual consraint (RC): {{{ forall b. () => (Show d, C d b) }}} and now `approximateWC` will produce only `Show d` from this, becuase `(C d b)` is captured by the `forall b`. What do to? Easy! Once we have decided "???" should be CX, say, just emit this implication (to be solved later): {{{ forall d. CX => RC }}} where RC is the residual constraint we computed earlier. Bingo! From CX we'll be able to solve all the constraints that `approximateWC` extracted, and we'll be left with the error that we want to report for that `(C d b)` constraint. ------------------ This may seem complicated, but it's '''exactly what happens in `TcSimplify.simplifyInfer`'''. It does a bit more besides (figuring out what type variables to quantify over), but it makes a good guide. We might ultimately wat to share code, but for now I think it's easier to do one step at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 11:31:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 11:31:02 -0000 Subject: [GHC] #13181: Introduce GHC.TypeNats module with natVal In-Reply-To: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> References: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> Message-ID: <060.a5da1886ce0ff8e2b949c676a32590c6@haskell.org> #13181: Introduce GHC.TypeNats module with natVal -------------------------------------+------------------------------------- Reporter: phadej | Owner: phadej Type: feature request | Status: patch 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): Phab:D3024 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This implementation is lacking motivation anywhere so I will add it in case anyone was wondering. One possible design choice would have been to keep the internal representation as an `Integer` and at the interface boundary do the error- checking when converting to a `Natural` once. Oleg preferred this implementation as it will cause the compiler to fail sooner if we accidentally do something like cause an interflow by subtracting or anything like that. The interface boundary is shifted to converting into `EvTerm`. There is a related ticket #13186 which talks about actually representing the evidence as `Natural` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 11:31:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 11:31:33 -0000 Subject: [GHC] #13181: Introduce GHC.TypeNats module with natVal In-Reply-To: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> References: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> Message-ID: <060.1a0f2309f916fceb83106a6568d5ea2e@haskell.org> #13181: Introduce GHC.TypeNats module with natVal -------------------------------------+------------------------------------- Reporter: phadej | Owner: phadej Type: feature request | Status: closed Priority: normal | Milestone: 8.2.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:D3024 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 11:34:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 11:34:57 -0000 Subject: [GHC] #13225: Fannkuch-redux time regression from join point patch In-Reply-To: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> References: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> Message-ID: <060.e2a0948f5501fe43c5f42c3b3ac685b2@haskell.org> #13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 12:43:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 12:43:47 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.07639e4caac352de83a1ed3e0c2b9eec@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sure it is! The `ConPatOut` has the type args of data con `pat_arg_tys`. And `dataConInstArgTys` will convert that list to a (singleton in this case) list of arg tys for the newtype constructor. Thanks for working on this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 12:52:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 12:52:12 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.c8835ed653da2184e521acf18dbaaf97@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The `pat_arg_tys` list is empty in this example, that was the first thing I tried. Is that a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 13:00:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 13:00:13 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.e44c8c8aeadbda9450b7f99276ed32ea@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): No, it's not a bug. Consdier {{{ newtype T a b c = MkT (c, Maybe (a,b)) f :: T Int [x] y -> Bool f (MkT v) = ... }}} In the `ConPatOut` for `MkT` the `pat_arg_tys` will be a 3-element list, of `Int`, `[x]`, and `y`. When you call `dataConInstArgTys MkT ` you'll get the singleton list back containing the type of `MkT`'s value arg: `(y, Maybe (Int,[x]))`. Now if `T` had no arguments thut {{{ newtype T = MkT (Int -> Int) }}} then of course `pat_arg_tys` will be empty, but `dataConInstArgTys` will return the singleton contianing `Int -> Int`. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 14:10:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 14:10:12 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.7550ecc847a63b999fa997c067b01157@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Some prior art we can draw on: Rust 1.15 has a "custom derive" feature that let's you derive any trait using its macro system: https://doc.rust- lang.org/book/procedural-macros.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 14:57:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 14:57:11 -0000 Subject: [GHC] #13219: CSE for join points In-Reply-To: <049.356ff616fe8ea0d0d5220b9d68f67a02@haskell.org> References: <049.356ff616fe8ea0d0d5220b9d68f67a02@haskell.org> Message-ID: <064.d9264a3a55ca7234ba197454f33854b8@haskell.org> #13219: CSE for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > We just need to track which join points are still currently valid. Yes, and that would not be hard. Just keep a join-point reverse map in the CSEnv, alongside the existing `cs_map`; and discard it when going into non-tail positions. A relatively easy win, but as you say a modest one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 15:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 15:04:13 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.9c99a965485f88cbee7b9154f4819218@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * Concerning the original ticket: I'd be perfectly happy if it became a warning. I agree that it's a bit odd if a program is accepted, but then after one beta-step it is rejected. (I'm not sure I'd call it type- unsound, which to me means that it's not rejected at all, but crashes at runtime.) * Concerning comment:15, good point. I think it might be quite tricky to make the 'deriving' mechanism predict which branches would be inaccessible; but perhaps possible. A significant advantage of making the error into a warning is that we could then ignore the warning in deriving code (we already ignore others). Happy to advise if someone would like to take this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 16:14:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 16:14:45 -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.bb6f4ecdec51de14064b6547b16c2dff@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks you Simon for the extra details. But I'm still quite fuzzy on some of the particulars. To be specific: 1. You've indicated that `approximateWC` is the way to go for retrieving the residual constraints out of an implication. But the type signature for `approximateWC` is more complicated than I expected: {{{#!hs approximateWC :: Bool -> WantedConstraints -> Cts -- Postcondition: Wanted or Derived Cts -- See Note [ApproximateWC] approximateWC float_past_equalities wc }}} In particular, there's this mysterious `float_past_equalities` argument. I've tried reading `Note [ApproximateWC]` to figure out what this means, but it talks about inferring most general types, which I'm not sure is relevant to this story or not. Should `float_past_equalities` be `True` or `False`? 2. I didn't really follow what you were trying to say here: Replying to [comment:14 simonpj]: > But we aren't done yet! Suppose we had written > {{{ > bar :: a -> b -> String > default bar :: (Show a, C a b) => a -> b -> String > }}} > I've replaced `Ix b` by `C b` and I've removed it from the vanilla sig for `Bar`. Now the implication constraint will be > {{{ > forall b. () => Show (Maybe d), C (Maybe d) b > }}} > Suppose we have `instance Read p => C (Maybe p) q`. Then after simplification, we get the residual constraint (RC): > {{{ > forall b. () => (Show d, Read d) > }}} > and all is well. But suppose we had no such instance, or we had an instance like `instance C p q => C (Maybe p) q`. Then we'd finish up with the residual consraint (RC): > {{{ > forall b. () => (Show d, C d b) > }}} > and now `approximateWC` will produce only `Show d` from this, becuase `(C d b)` is captured by the `forall b`. What do to? > > Easy! Once we have decided "???" should be CX, say, just emit this implication (to be solved later): > {{{ > forall d. CX => RC > }}} > where RC is the residual constraint we computed earlier. Bingo! From CX we'll be able to solve all the constraints that `approximateWC` extracted, and we'll be left with the error that we want to report for that `(C d b)` constraint. > > ------------------ > This may seem complicated, but it's '''exactly what happens in `TcSimplify.simplifyInfer`'''. It does a bit more besides (figuring out what type variables to quantify over), but it makes a good guide. We might ultimately wat to share code, but for now I think it's easier to do one step at a time. > > First of all, you jumped from a concrete example to `forall d. CX => RC` halfway through. What are `CX` and `RC` here? Why did we switch from `forall b.` to `forall d.`? Also, should I interpret this as meaning that if there are any implication constraints leftover after solving which contain something of the form `forall x. C => Foo x` (i.e., if there are constraints which contain type variables other than the class's type variables), that should be an error? Do we already take care of this with [http://git.haskell.org/ghc.git/blob/bbd3c399939311ec3e308721ab87ca6b9443f358:/compiler/typecheck/TcDerivInfer.hs#l563 these lines] in `TcDerivInfer`: {{{#!hs ; (implic, _) <- buildImplicationFor tclvl skol_info tvs_skols [] unsolved -- The buildImplicationFor is just to bind the skolems, -- in case they are mentioned in error messages -- See Trac #11347 -- Report the (bad) unsolved constraints ; unless defer (reportAllUnsolved (mkImplicWC implic)) }}} Or does something else need to happen? Finally, I'm rather confused by your comments about `simplifyInfer`. Are you saying that I should literally use` simplifyInfer` to solve these implications, or that I should be copy-pasting code from `simplifyInfer` for this use case? If it's the former, how do I invoke `simplifyInfer`? Its type signature is rather daunting: {{{#!hs simplifyInfer :: TcLevel -- Used when generating the constraints -> InferMode -> [TcIdSigInst] -- Any signatures (possibly partial) -> [(Name, TcTauType)] -- Variables to be generalised, -- and their tau-types -> WantedConstraints -> TcM ([TcTyVar], -- Quantify over these type variables [EvVar], -- ... and these constraints (fully zonked) TcEvBinds) -- ... binding these evidence variables }}} In particular, I'm unfamiliar with what the `InferMode`, `[TcIdSigInst]`, and `[(Name, TcTauType)]` arguments should be, and if the returned `TcEvBinds` is relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 16:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 16:34:51 -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.d7d41820200103667f30f63206f7a3c5@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > but it talks about inferring most general types, which I'm not sure is relevant to this story or not Yes it's relevant. In inferring "???" we are indeed trying to infer the most general type for the instances. We seek the context with fewest constraints (i.e. most general). The equalities thing doesn't matter much, but for consistency with `simplifyInfer` set it to `True`. > What are CX and RC here? I defined them earlier in the text you quoted! RC = residual context, CX is what we decide ??? should be. > Also, should I interpret this as meaning that if there are any implication constraints leftover after solving which contain something of the form forall x. C => Foo x (i.e., if there are constraints which contain type variables other than the class's type variables), that should be an error? Yes, certainly. Notice that `approximateWC` doesn't remove the constraints it floats out; it just floats them out. They are still there in RC; but we'll solve them easily from CX. > Do we already take care of this with ​these lines in TcDerivInfer: I'm not sure.. too much is in flux. But you don't need to solve it because you don't need to know the answer here: just emit it and it'll get solved later. > Are you saying that I should literally use simplifyInfer to solve these implications No: sharing code with `simplifyInfer` in due course would be a good plan, but it does a lot more so just use it as a source of inspiration, no more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 16:39:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 16:39:15 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.fb91365944feab89794f8c471ffb7a50@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"09b8332df92428fe1be780c8a6bbcdd4c341a50d/ghc" 09b8332d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="09b8332df92428fe1be780c8a6bbcdd4c341a50d" Get rid of ProbOneShot This fixes #13227. It remains to be seen what the performance impacts are. Pushing as a branch to get perf.haskell.org answer that for us. Differential Revision: https://phabricator.haskell.org/D3067 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 16:44:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 16:44:51 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.da4e0411cb0c666be819c818688bb51d@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Will you pursue comment:9? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 16:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 16:46:29 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.2882c267b20b424f8d0c021466b9d5ee@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -7,0 +7,2 @@ + * `perf/compile/T9020`: see + [https://git.haskell.org/ghc.git/commitdiff/c2becee48aa73795cbf04905f3891f543f1c746e] New description: Need to look at some modest performance regressions for the main join- point patch (#12988, wiki [wiki:SequentCore]): * `perf/compiler/T9961`: `bytes_allocated` * `perf/compiler/T10356`: `bytes_allocated` * `perf/compiler/T1969`: `max_bytes_used` * `perf/compile/T9020`: see [https://git.haskell.org/ghc.git/commitdiff/c2becee48aa73795cbf04905f3891f543f1c746e] * `deriving/perf/T10858`: `bytes_allocated` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 16:56:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 16:56:57 -0000 Subject: [GHC] #13229: Add -ddump-inlinings-reasoning Message-ID: <046.b1c694603a7d0552b77859f5471e8542@haskell.org> #13229: Add -ddump-inlinings-reasoning -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- It always takes me a while (usually by reading the source code) that `-ddump-inlinings` is not as useful as I want it to be without `-dverbose- core2core`. This just happened to me yesterday. But the latter is very verbose! In changeset:6128b2ffbe36ed2779583e05ee9d817eaafc1c9c Ben documented this behaviour (thanks!) but it is still annoying. Can we not have a flag `-ddump-inlinings-reasoning` that enables the more verbose variant of `-ddump-inlinings` independent of `-dverbose- core2core`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 17:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 17:02:36 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.f4eaca4d13901455cad7c56508a72017@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Just wanted to drop a note here: I'm still trying to create a minimal example that I can share for the experts to look at. Unfortunately, my attempts so far failed: Any meaningful reduction of the code and the lint- error goes away. I haven't given up however; and I'm hopefull I'll be able to share something next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 17:15:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 17:15:07 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.f30b968c46eac43f5ed321a783a159d3@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sadly, the lint error is a bug in lint. In the conversion from Core to STG we replace `(Coercion blah)` with `coercionToken#`; the latter has a fixed type. It's just a placeholder. STG lint complains about this but it shouldn't; we could have recorded the type in `corecionToken#` (maybe by having variants or something) but it'd just be work to no gain. So I am sill clueless about why this `stg_app_ppp` thing is happening, sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 17:37:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 17:37:34 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.3a2c3ab8b0fe9e76d4ad50229a867129@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The proposed new defaulting rules in the patch are: Find all the unsolved constraints. Then: * Find those of form `(C t1 ... a ... tn)`, where `C` is a class, and `a` is a type variable of kind `Type` or `(Type -> Type)`, and all the other parameters of `C` have kinds other than `Type` or `Type -> Type`. * Partition this set into groups that share a common type variable `a`. * Now default `a` (to one of the types in the default list) if * The type variable `a` appears in no other constraint outside that group * At least one of the classes `Ci` is an interactive class ("Interactive class" is defined [http://downloads.haskell.org/~ghc/master /users-guide/ghci.html#type-defaulting-in-ghci here].) This seems a bit complicated to me. What about this instead. Find all the unsolved constraints. Then: * Find those that have exactly one free type variable, and partition that subset into groups that share a common type variable `a`. * Now default `a` (to one of the types in the default list) if at least one of the classes `Ci` is an interactive class This is a bit more flexible, and a bit simpler to describe. The "just one free type variable" part is meant to avoid having to look for ''combinations'' of defaulting types that will allow the constraint to be solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 19:19:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 19:19:14 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.471b1c99bd80b7050a574ddf5cd3ddd2@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => new * owner: nomeata => Comment: > According to perf.haskell.org (which does run nofib!), the only significant changes are time improvements of 3.5% for cacheprof and k-nucleotid. Indeed, these improvements (with -2.7% resp. -4.16% for the final commit) seem to be genuine, and not just flaky measurements. :-) > Will you pursue comment:9? Will give it a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 19:19:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 19:19:23 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.068884db24a8f5b7195c322ce27fce1a@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 20:54:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 20:54:14 -0000 Subject: [GHC] #13230: Something strange with "Don't use the splitter on Darwin" Message-ID: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> #13230: Something strange with "Don't use the splitter on Darwin" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 8.2.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: -------------------------------------+------------------------------------- Commit 266a9dc4cd34008f1162eb276032c85ef8371842 "Don't use the splitter on Darwin" sounds like it should only affect Darwin, but the perf results indicate otherwise, even though perf.haskell.org builds are done on a linux machine: https://perf.haskell.org/ghc/#revision/266a9dc4cd34008f1162eb276032c85ef8371842 Total build time went up 13.7% and all nofib object sizes became much larger. I suspect the splitter was disabled completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 22:05:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 22:05:45 -0000 Subject: [GHC] #13230: Something strange with "Don't use the splitter on Darwin" In-Reply-To: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> References: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> Message-ID: <062.a553f51e93eefc40a790ae21832c3e28@haskell.org> #13230: Something strange with "Don't use the splitter on Darwin" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 8.2.1 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): Phab:D3070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D3070 Comment: Using split sections by default (as opposed to split objects) was accidentally disabled, so the perf results were the reverse of https://perf.haskell.org/ghc/#revision/8f71d9581ee0a1826c0105e51a7048f0c7669492. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 22:26:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 22:26:10 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.a79ad8426651615cb5c401778fcd75e4@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: dfeuer Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Core Libraries | 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: | Differential Rev(s): Phab:D3038 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"2f5cb3d44d05e581b75a47fec222577dfa7a533e/ghc" 2f5cb3d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f5cb3d44d05e581b75a47fec222577dfa7a533e" Attempt to make lazy ST thread safe Use `noDuplicate#` to prevent lazy `ST` thunks from being evaluated in multiple GHC threads. Some lazy `ST` functions added laziness that did not seem to be useful (e.g., creating lazy pairs that will never be matched unless one of their components is demanded). Stripped that out. Reviewers: ekmett, simonpj, bgamari, simonmar, austin, hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3038 GHC Trac Issues: #11760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 23:31:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 23:31:42 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.6c2214f2ed157fb562d3c84d8634d072@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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:D3073 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3073 Comment: Done it. Also had to make sure no binders are maked as `Dead`. See Phab:D3073. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 23:33:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 23:33:03 -0000 Subject: [GHC] #10823: Don't mark functions with annotations as dead In-Reply-To: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> References: <045.57db4451919a86b3fcad053f0c16d552@haskell.org> Message-ID: <060.c90bacb5e6c8c5ef18da87645354733f@haskell.org> #10823: Don't mark functions with annotations as dead -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | 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: #11179 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate Comment: Closing this as a duplicate of #10823. see Phab:D3073 for a solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 23:33:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 23:33:16 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.b2d3fb9aaacf97da0ce7666b6de37176@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #10823 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 3 23:48:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Feb 2017 23:48:06 -0000 Subject: [GHC] #13171: panic on negative literal in case on Word In-Reply-To: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> References: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> Message-ID: <062.014d794324c5ab4cd1a4662397d3ab8f@haskell.org> #13171: panic on negative literal in case on Word -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): In fact I had forgotten that I did use to know something about this. Phab:D810 would fix this issue also. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 01:19:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 01:19:09 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.cd93a1aa86c31dfbf574fef19ffa120b@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I'm not sure that keeping dead top-level binders is sufficient. I believe that `simpleOptPgm` does other things that cause trouble for analysis tools. For example, IIRC it will automatically inline single-use, unexported binders. It would be nice if plugins could see a "faithful" representation of the source code, i.e. as close to the parsed HsSyn as possible. I realize this is a bit out of scope with respect to the original ticket, happy to file a separate ticket with a concrete example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 02:27:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 02:27:24 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.c5147c21c331d40fa753972cb22d984e@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): ha, here is a hack to keep things alive: {{{ module Test () where foo = foo {-# RULES "keeps foo alive" id foo = foo #-} }}} I will try revise Phab:D3073 with a nicer approach, but for people stuck with older versions of GHC, this is might help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 03:35:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 03:35:37 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.65d709985cfca82d031e73c1098c1769@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I realize this is a bit out of scope with respect to the original ticket, happy to file a separate ticket with a concrete example. I guess that’s worth a separate ticket. Maybe we want plugins that run on the type-checked code before desugaring? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 05:29:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 05:29:55 -0000 Subject: [GHC] #13225: Fannkuch-redux time regression from join point patch In-Reply-To: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> References: <045.57680e4c43bc3ae385303982924a0a94@haskell.org> Message-ID: <060.a9fae7b43caafae9e21bea0989bd51a5@haskell.org> #13225: Fannkuch-redux time regression from join point patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sibi): * cc: sibi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 10:33:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 10:33:08 -0000 Subject: [GHC] #13230: Something strange with "Don't use the splitter on Darwin" In-Reply-To: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> References: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> Message-ID: <062.8261f57aa302c6e4ae17f171da9f3019@haskell.org> #13230: Something strange with "Don't use the splitter on Darwin" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: high | Milestone: 8.2.1 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): Phab:D3070 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"283acec1d7307fdbd8cd7b3f1d984a036366d6b4/ghc" 283acec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="283acec1d7307fdbd8cd7b3f1d984a036366d6b4" Make split sections by default work again Commit 266a9dc4c changed = to := in one place in mk/config.mk.in. This broke SupportsSplitSections because the variable LdIsGNULd that it depends on is not defined until later in the file. Test Plan: pushed to a wip/ branch for perf to build Reviewers: DemiMarie, austin, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D3070 GHC Trac Issues: #13230 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 10:38:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 10:38:49 -0000 Subject: [GHC] #13230: Something strange with "Don't use the splitter on Darwin" In-Reply-To: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> References: <047.a8a418f025e6a4b5d45c3e12be52fc43@haskell.org> Message-ID: <062.ebd8a9c650a68431534632d7036083e3@haskell.org> #13230: Something strange with "Don't use the splitter on Darwin" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 10:51:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 10:51:19 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.464e0ab910164ff4275aa5c8d249307b@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -19,0 +19,7 @@ + + Edit: `-fexpose-all-unfoldings` plus `-fspecialise-aggressively` is a + perfect workaround. I wish somebody told me earlier. Compared to 600 + `INLINABLE` and `-fexpose-all-unfoldings`, the compilation time is + unchanged (10min) and the program seems a bit faster (not a scientific + benchmark). Profiling works fine with this setup and I don't need to write + `INLINABLE` any more (nor add `SCC` by hand). New description: Judging from .prof files and the -xc and -prof callstacks, GHC adds no automatic SCC annotations for functions marked `INLINABLE`. The user's guide only mentions `INLINE`: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html, not `INLINABLE`. Is it a bug in documentation or implementation? In my case I managed to work around by using `-fexpose-all-unfoldings` instead of the tons of `INLINABLE` I was using before, but in general case, adding all the SCC annotations by hand seems prohibitive. e.g., in code that needs a lot of `INLINABLE` to enable specialization. Since `-fexpose-all-unfoldings` does not inhibit profiling and compiling with no optimization doesn't help recover it, the culprit is probably not the actual inlining or specialization, but rather handling of the `INLINABLE` pragma itself. Edit: Ufortunately, the workaround by using `-fexpose-all-unfoldings` turns out to be not acceptable for me, see #12963. I'm also no longer sure about the last paragraph. Edit: `-fexpose-all-unfoldings` plus `-fspecialise-aggressively` is a perfect workaround. I wish somebody told me earlier. Compared to 600 `INLINABLE` and `-fexpose-all-unfoldings`, the compilation time is unchanged (10min) and the program seems a bit faster (not a scientific benchmark). Profiling works fine with this setup and I don't need to write `INLINABLE` any more (nor add `SCC` by hand). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 10:59:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 10:59:25 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.5ba16256adfafa19c4636f88872d54aa@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I'd like to point out that the combination of `-fexpose-all-unfoldings` plus `-fspecialise-aggressively` has the effect of `INLINEABLE` on all overloaded functions in the program. This is much less fine grained than the proposed `SPECIALISE_RECURSIVE`, but it works for me at the cost of much higher compilation times (e.g., travis now refuses to compile my program with `-O2 due to memory constraints). I wish somebody told me about that trick before I added my 600 `INLINABLE` and started writing corresponding 600 `SCC` pragmas by hand, so I'm sharing here. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 11:05:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 11:05:02 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.8f3fbdf4e8267050a5654e045be9e919@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I recently documented `-fspecialise-aggressively` if people are wondering what it does. https://phabricator.haskell.org/rGHCa8c81f3c102988e0f4216b7cb5fec7958e60b4e4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 14:02:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 14:02:52 -0000 Subject: [GHC] #13231: ghc: panic! (the 'impossible' happened) Message-ID: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> #13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- '''The crash happens during "stack build" after I updated the resolver to lts-6.30 ''' {{{ -- While building package yesod-auth-1.4.13.5 using: /Users/aufheben/.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: /Users/aufheben/stack/iped/.stack-work/logs /yesod-auth-1.4.13.5.log Configuring yesod-auth-1.4.13.5... Building yesod-auth-1.4.13.5... Preprocessing library yesod-auth-1.4.13.5... [ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o ) /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o ) /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:23:1: Warning: The import of ‘mappend’ from module ‘Data.Monoid’ is redundant /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:698:1: Warning: Defined but not used: ‘croatianMessage’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are overlapped In an equation for ‘finnishMessage’: finnishMessage Password = ... /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘finnishMessage’: Patterns not matched: CurrentPassword [ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o ) [ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/ghc62638_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/ghc62638_0/libghc_21.dylib: malformed mach-o: load commands size (36088) > 32768 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 Feb 4 14:03:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 14:03:19 -0000 Subject: [GHC] #13231: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> References: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> Message-ID: <062.2f4979a5ea8739cdb8581f9d02963e64@haskell.org> #13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aufheben): * Attachment "yesod-auth-1.4.13.5.log" added. log file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 14:07:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 14:07:56 -0000 Subject: [GHC] #13231: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> References: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> Message-ID: <062.8d302c8b5162f1c1705b44fb5320bc1a@haskell.org> #13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * priority: highest => normal * resolution: => duplicate Comment: This is a duplicate of #12479, please upgrade to 8.0.2. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 14:10:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 14:10:07 -0000 Subject: [GHC] #13231: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> References: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> Message-ID: <062.2b404f51dfb138f86db4fdd3c7e6ed0b@haskell.org> #13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aufheben): * status: closed => new * resolution: duplicate => @@ -1,2 +1,2 @@ - '''The crash happens during "stack build" after I updated the resolver to - lts-6.30 + '''The crash happens during "stack build" of my project. Resolver version + is lts-6.23. New description: '''The crash happens during "stack build" of my project. Resolver version is lts-6.23. ''' {{{ -- While building package yesod-auth-1.4.13.5 using: /Users/aufheben/.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: /Users/aufheben/stack/iped/.stack-work/logs /yesod-auth-1.4.13.5.log Configuring yesod-auth-1.4.13.5... Building yesod-auth-1.4.13.5... Preprocessing library yesod-auth-1.4.13.5... [ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o ) /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o ) /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:23:1: Warning: The import of ‘mappend’ from module ‘Data.Monoid’ is redundant /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:698:1: Warning: Defined but not used: ‘croatianMessage’ /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are overlapped In an equation for ‘finnishMessage’: finnishMessage Password = ... /private/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/stack62597 /yesod-auth-1.4.13.5/Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘finnishMessage’: Patterns not matched: CurrentPassword [ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o ) [ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/ghc62638_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/pl/w67yh9w96k3dnkbs3slbk2gw0000gn/T/ghc62638_0/libghc_21.dylib: malformed mach-o: load commands size (36088) > 32768 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 Feb 4 14:11:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 14:11:18 -0000 Subject: [GHC] #13231: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> References: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> Message-ID: <062.8ec4b66a5aa26fbf215b76b5fbca1779@haskell.org> #13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #12479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 14:14:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 14:14:46 -0000 Subject: [GHC] #13231: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> References: <047.2b640fc664a4a457033bc44c8b080eef@haskell.org> Message-ID: <062.2852d6a5be992a6a50a880151e846146@haskell.org> #13231: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aufheben): Thanks! Sorry that I accidentally reopened the issue after editing the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 15:14:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 15:14:19 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.63604c5f270a764ee503e3c79010a32c@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks Simon. That makes sense, I updated the diff now and also the old test for #9844 to test the strictness properties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 15:24:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 15:24:55 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.e985cc60ec49eee379f361f8fdd6f330@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3065, Wiki Page: | Phab:D3064 -------------------------------------+------------------------------------- Comment (by mpickering): In the original ticket, the record update gets desugared to something like {{{#!hs case emptyA of BFields _ -> BFields [a] _ -> error "Non-exhaustive patterns..." }}} GHC then warns that the first branch is inaccessible, which is true as the type of `emptyA` means that the value has to be either `EmptyFields` or `AFields`. At run-time, evaluating `f ()` causes a run-time error. So, is there anything here to fix apart from the panic? Usually warnings which affect incomplete pattern match warnings are only turned on by `-Wincomplete-record-updates`. This is however, a warning about inaccessibility/redundancy rather than incompleteness. What do you expect to happen niteria? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 17:02:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 17:02:42 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.e2e25a0738db5e2f946825543d5cbf8c@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by quyse): Replying to [comment:9 awson]: > FYI, I've built (slightly patched) GHC HEAD (170118) with `USE_LARGE_ADDRESS_SPACE` enabled. > > Now it automatically allocates main heap at 2GB mark (no need to give any extra options, since Windows already can't find 1TB or contiguous address space starting below 2GB mark) and things work '''perfectly'''. > > Apparently, also there are no problems with `USE_LARGE_ADDRESS_SPACE` on W10 1607. Woohoo! Hi, I'm seeing these segfaults on Windows too with GHC 8.0.2 building my own code using TH. Is there a GHC patch I can apply to fix this? I tried using `-fexternal-interpreter`, it works on development machine, but frequently hangs indefinitely on CI machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 17:06:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 17:06:23 -0000 Subject: [GHC] #13080: Memory leak caused by nested monadic loops In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.6aef73204733398d79df2e96bcaab688@haskell.org> #13080: Memory leak caused by nested monadic loops -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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 michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 17:07:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 17:07:12 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.40c82a0d68a02887c659a655a839f3b7@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 17:09:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 17:09:21 -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.c8f90cf9ef7681bf77c80fb4cffc450d@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | 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: #1062, #1176, | Differential Rev(s): Phab:D1130, #7666, #8809 | Phab:D1132 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 18:11:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 18:11:02 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.039ac8ef8334ca87f923903da19fec85@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): > Again this [a type family instance must have been imported if it matches a lookup] is guaranteed for non-orphan instances. There's at least one hole in this scheme, from `OverloadedLists`. Consider this program {{{#!hs {-# LANGUAGE OverloadedLists #-} module Ol where -- import GHC.Exts f :: [Bool] f = [True] }}} The literal `[True]` means `GHC.Exts.fromListN 1 (True : [])` where `GHC.Exts.fromListN :: Int -> [Item l] -> l`. So we can only accept the program if we have the instance `Item [a] ~ a` in scope. That instance is defined in `GHC.Exts` along with the `Item` type family. But note that we never imported `GHC.Exts`; yet the renamer inserted a reference to `GHC.Exts.Item` directly. This is the root cause of the problem, that the renamer inserted a reference to something that wasn't imported. On my branch, the program as above is rejected because the `Item [a] ~ a` instance is not imported. That's sort of logical, but not the desired behavior. If you uncomment the `import GHC.Exts` line, then the program is accepted. I haven't yet implemented the "optimization" that treats all type family instances as visible if they are non-orphan. I use quotes because, as seen above, it's not actually true, and it would change behavior: in this case it would change it to the desired behavior. Considering the consistency checking scheme is based on instances that are imported, is it okay to treat this instance as visible? I think it is okay in this case, because the ''type family'' `Item` is defined in the same module that the instances live in. That means it's impossible for any module to define instances of `Item` without them being consistency checked against the instances in `GHC.Exts` that are implicitly globally visible. So, it's still impossible to ever have an inconsistent set of visible type family instances. Note that this argument does not just rest on the `Item [a] ~ a` instances being non-orphan. If we had a globally visible instance that was non- orphan because it mentioned a type defined in the same module, it would be possible to write a conflicting instance without importing the former instance, and then the consistency checking scheme would fail. So, this is another example of the constraint I mentioned in comment:6: if `X` is a magic/wired-in thing that can be in scope without being imported, then type family instances for `X` must be defined in the module which defines the type family, not in the module which defines `X`. In fact, I think we can clarify this whole situation just by changing the definition of orphan slightly. The note [When exactly is an instance decl an orphan?] says > Roughly speaking, an instance is an orphan if its head (after the `=>`) mentions nothing defined in this module. But I think the real intent is > an instance is an orphan if its head (after the `=>`) mentions nothing ''that you need to import this module to see''. For example, you can write the tuple type constructor `(,)` even if you import nothing at all. So that means that an `instance Foo (,)` should still be treated as an orphan instance even if it is defined in the module defining `(,)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 19:56:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 19:56:34 -0000 Subject: [GHC] #13232: Undeflow/overflow for floating-point values Message-ID: <045.a50b5cb8e354f5c4c14250d80a77cb47@haskell.org> #13232: Undeflow/overflow for floating-point values -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- GHC nicely prints overflow for bounded types: {{{#!hs Prelude Data.Word> 232312::Word8 :2:1: warning: [-Woverflowed-literals] Literal 232312 is out of the Word8 range 0..255 120 }}} But the same courtesy isn't currently extended to floats: {{{ Prelude Data.Word> 1e5000 :: Float Infinity Prelude Data.Word> 1e-5000 :: Double 0.0 }}} It would be nice if overflow/underflow warnings were issued for floats as well. Note that with the hexadecimal floats proposal (https://github.com/LeventErkok/ghc- proposals/blob/hexFloats/proposals/0000-hexFloats.rst) this would be especially nice, making GHC a very fine platform for numeric computations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 19:57:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 19:57:46 -0000 Subject: [GHC] #13232: Undeflow/overflow warnings for floating-point values (was: Undeflow/overflow for floating-point values) In-Reply-To: <045.a50b5cb8e354f5c4c14250d80a77cb47@haskell.org> References: <045.a50b5cb8e354f5c4c14250d80a77cb47@haskell.org> Message-ID: <060.37f09104b435a1c6ff92cba82c62cd0f@haskell.org> #13232: Undeflow/overflow warnings for floating-point values -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lerkok: @@ -1,1 +1,1 @@ - GHC nicely prints overflow for bounded types: + GHC nicely prints overflow warnings for bounded types: New description: GHC nicely prints overflow warnings for bounded types: {{{#!hs Prelude Data.Word> 232312::Word8 :2:1: warning: [-Woverflowed-literals] Literal 232312 is out of the Word8 range 0..255 120 }}} But the same courtesy isn't currently extended to floats: {{{ Prelude Data.Word> 1e5000 :: Float Infinity Prelude Data.Word> 1e-5000 :: Double 0.0 }}} It would be nice if overflow/underflow warnings were issued for floats as well. Note that with the hexadecimal floats proposal (https://github.com/LeventErkok/ghc- proposals/blob/hexFloats/proposals/0000-hexFloats.rst) this would be especially nice, making GHC a very fine platform for numeric computations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 19:58:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 19:58:23 -0000 Subject: [GHC] #13232: Undeflow/overflow warnings for floating-point values In-Reply-To: <045.a50b5cb8e354f5c4c14250d80a77cb47@haskell.org> References: <045.a50b5cb8e354f5c4c14250d80a77cb47@haskell.org> Message-ID: <060.b0083607a90e95364b707268ad90a2a6@haskell.org> #13232: Undeflow/overflow warnings for floating-point values -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lerkok: @@ -14,1 +14,1 @@ - Prelude Data.Word> 1e5000 :: Float + Prelude> 1e5000 :: Float @@ -16,1 +16,1 @@ - Prelude Data.Word> 1e-5000 :: Double + Prelude> 1e-5000 :: Double New description: GHC nicely prints overflow warnings for bounded types: {{{#!hs Prelude Data.Word> 232312::Word8 :2:1: warning: [-Woverflowed-literals] Literal 232312 is out of the Word8 range 0..255 120 }}} But the same courtesy isn't currently extended to floats: {{{ Prelude> 1e5000 :: Float Infinity Prelude> 1e-5000 :: Double 0.0 }}} It would be nice if overflow/underflow warnings were issued for floats as well. Note that with the hexadecimal floats proposal (https://github.com/LeventErkok/ghc- proposals/blob/hexFloats/proposals/0000-hexFloats.rst) this would be especially nice, making GHC a very fine platform for numeric computations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 23:08:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 23:08:25 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.6249a9991d3bedb12639f3c20cdc2fea@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | 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 performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D3001 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"29122312cc7b8f9890eb53f92d76ecdd8ded24ee/ghc" 2912231/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29122312cc7b8f9890eb53f92d76ecdd8ded24ee" Improve wrapTicks performance with lots of redundant source notes The old version had O(n^3) performance for n non-overlapping source notes and let floats each, which is exactly what happens with -g if we compile a list literal of length n. The idea here is simply to establish early which source notes will actually survive (e.g. use a left fold). The new code should be O(n) for list literals. Reviewers: austin, dfeuer, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3037 GHC Trac Issues: #11095 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 23:08:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 23:08:25 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.932ad7edd651dc33348f633b6a78d32e@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3065, Wiki Page: | Phab:D3064 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"68cbe52fd3ae618a9778e79bf6a9806bab21aff2/ghc" 68cbe52f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68cbe52fd3ae618a9778e79bf6a9806bab21aff2" Don't panic when printing match with RecUpd context Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3065 GHC Trac Issues: #12957 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 23:09:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 23:09:37 -0000 Subject: [GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) In-Reply-To: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> References: <045.f2278fefc782dbe6a8ba94b4e136cda3@haskell.org> Message-ID: <060.7d09c2b86c0fbd911433ada72a0959ae@haskell.org> #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 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:D3001 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 23:10:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 23:10:07 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.d00383ef38485560b78d579f29c6c2e7@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3065, Wiki Page: | Phab:D3064 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * version: => 8.1 * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 4 23:32:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Feb 2017 23:32:54 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.d6a1bea9d3e81e07eb84e118fbfbc297@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 ezyang): Just popping in: rwbarton, in the overloaded lists case, why don't we just consider `GHC.Exts` as visible always? In fact, we already do something like this for wired in things: see `Note [Loading instances for wired-in things]`. There should only be a fixed number of these... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 03:33:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 03:33:07 -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.94df48222cbd5ba8b8488231c4057341@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 mittenchops): Hi! I'd like to signal boost this, please. I had a related question on StackOverflow: http://stackoverflow.com/questions/42046459/haskell- optarse-generic-example-failing-on-typeoperators-and-datakinds/42046849 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:01:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:01:10 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling Message-ID: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am seeing this panic while compiling GHC stage2, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170124 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a :: TYPE k0) k0 Call stack: ?callStack, called at compiler/utils/Util.hs:1352:50 in ghc:Util prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> compiler/ghc.mk:582: recipe for target 'compiler/stage2/build/StgCmmMonad.p_o' failed }}} This appears to be due to my enabling of profiling. `build.mk` contains, {{{ BuildFlavour=prof ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif HADDOCK_DOCS=YES compiler_HC_OPTS += -fprof-auto-exported }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:02:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:02:18 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.4b35db4c4cff3871ee702fafc1c17976@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm seeing this on 9fd87ef8a16fbbce35205ae63d75d239bb575ccc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:04:50 -0000 Subject: [GHC] #13234: Yesod and Persistent cause compiler panic Message-ID: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> #13234: Yesod and Persistent cause compiler panic ----------------------------------------+--------------------------------- Reporter: cheshircat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hello, This is my first bug report for GHC, so excuse me if I don't have all the formatting correct, and please tell me how to correct it! I am working on a yesod app, and upon running cabal run, I got this message: {{{#!hs Preprocessing executable 'creative-index-org' for creative-index- org-0.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/creative-index- org/creative-index-org-tmp/Main.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] person_aodw :: t_aodv[tau:1] (CHoleCan: person)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have attached Main.hs, the cabal file, and a nix-shell file (in case you use nix) that contains the environment I was running this in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:05:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:05:13 -0000 Subject: [GHC] #13234: Yesod and Persistent cause compiler panic In-Reply-To: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> References: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> Message-ID: <064.ba99e7f00908f3926296ca122d452add@haskell.org> #13234: Yesod and Persistent cause compiler panic ---------------------------------+---------------------------------------- Reporter: cheshircat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by cheshircat): * Attachment "creative-index-org.cabal" added. Cabal file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:05:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:05:38 -0000 Subject: [GHC] #13234: Yesod and Persistent cause compiler panic In-Reply-To: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> References: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> Message-ID: <064.fccfacc88b6fa48713cdeee2ab946c68@haskell.org> #13234: Yesod and Persistent cause compiler panic ---------------------------------+---------------------------------------- Reporter: cheshircat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by cheshircat): * Attachment "Main.hs" added. Haskell file with code that causes the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:06:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:06:06 -0000 Subject: [GHC] #13234: Yesod and Persistent cause compiler panic In-Reply-To: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> References: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> Message-ID: <064.cb4ab7c0530d770cb605d59d140f41d9@haskell.org> #13234: Yesod and Persistent cause compiler panic ---------------------------------+---------------------------------------- Reporter: cheshircat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by cheshircat): * Attachment "shell.nix" added. shell.nix file that recreates my environment (note, I am on nixos- unstable) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:44:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:44:12 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.eb024dd9a9713b8ad19dd03aa977bd85@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a more complete backtrace, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170124 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a :: TYPE k0) k0 Call stack: ?callStack, called at compiler/utils/Util.hs:1352:50 in ghc:Util prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:358:5 in ghc:RepType runtimeRepPrimRep, called at compiler/simplStg/RepType.hs:340:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:303:18 in ghc:RepType typePrimRep, called at compiler/simplStg/RepType.hs:67:11 in ghc:RepType typePrimRepArgs, called at compiler/simplStg/RepType.hs:108:13 in ghc:RepType countFunRepArgs, called at compiler/basicTypes/Id.hs:570:19 in ghc:Id idFunRepArity, called at compiler/codeGen/StgCmmClosure.hs:334:13 in ghc:StgCmmClosure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 04:45:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 04:45:10 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.4a2256c9c2312416248e9fecb7de6fe8@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, it seems that `mkLFImported` was looking at this `Id`, {{{ (#,#) :: forall (a :: TYPE k0) (b :: TYPE k1). a -> b -> (# a, b #) }}} Something is indeed amiss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 05:34:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 05:34:03 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.1b0bf4bed8007dc8ac6521f14fe748b4@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Unboxed tuples should be long gone by then, shouldn't they? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 05:57:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 05:57:19 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.89078bbecb6bc2f41cff4ebcb9b67ac0@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by amindfv): Simon: this seems like a really elegant solution to me. Starting work on it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 07:03:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 07:03:14 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.19ba7ac0e75a254ab720fcecf2eb0d57@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukemaurer): * status: new => patch * differential: => D3080 Comment: Found two causes: * In several files, the problem was a mistake with occurrence-analyzing rules: {{{ let $sj = \y ys -> ... {-# RULES "SC:j" forall y ys. j (y:ys) = $sj y ys #-} j = \xs -> ... in ... }}} Here `j` can be a join point of join arity 1. Since its rule matches exactly one argument (same as the join arity), the body of its RHS can contain tail calls (see Note [Rules and join points] in OccurAnal). Thus `$sj` can also be a join point, since its only occurrence is a tail call with two arguments. But by mistake, OccurAnal is counting the binders of the rule, not the arguments on its RHS; since there are two binders and `j`'s join arity is 1, `$sj` gets rejected as a potential join point. The warning appears because in the case that `j` is a join point to begin with and SpecConstr specializes it, `$sj` will be created as a join point, so if OccurAnal doesn't think it can be a join point it issues the warning. * In T7796, the problem is that we're zapping too much when looking at stable unfoldings; we should be allowing unfoldings for join points to have tail calls. {{{ let j1 = \x -> ... j2 [Unf=\y -> j1 y] j2 = \y -> j1 y in ... j2 a {- tail call -} ... }}} Here both `j1` and `j2` should be made join points, but to know that we have to see that the call to `j1` from the unfolding of `j2` is a tail call. Again, the warning arises from a join point getting specialized; if `j1` is a specialization of `j2`, failing to discover `j1` as a join point produces the warning. Submitted a patch to Phab. This doesn't fix //all// the instances of the warning, but it fixes the noisy ones that show up in test cases. (The remaining source of noise is beta redexes arising from the simple optimizer; that's an ongoing issue. Fortunately, when that causes a warning, it'll only show up once before the simplifier gets rid of the beta redex.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 16:02:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 16:02:10 -0000 Subject: [GHC] #13234: Yesod and Persistent cause compiler panic In-Reply-To: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> References: <049.a34edbe64366a7a8b7eed8379924647f@haskell.org> Message-ID: <064.df3fe53537c0bd3700b0d2cc71bf7259@haskell.org> #13234: Yesod and Persistent cause compiler panic ---------------------------------+---------------------------------------- Reporter: cheshircat | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12921 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12921 Comment: Thanks for the bug. This is a duplicate of #12921, which has been fixed upstream and will be included in the soon-to-be-released GHC 8.2. Until then, note that this bug is caused by out-of-scope identifiers being used in certain places. In your case, it looks like the out-of-scope identifier is named `person`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 16:11:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 16:11:15 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.f3cce76309c9aed916f0e09f144fc96b@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, that is my understanding as well. Incidentally, `-dstg-lint` appears to hang. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 17:39:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 17:39:22 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.954c06d43c693ecf38b87161ab03824e@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I gave it a shot, but something is clearly still wrong, I get huge regressions in performance tests. I will try counting only the length of the `OneShot` prefix of `occ_one_shots` (which seems to make more sense to me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 21:48:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 21:48:37 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.23fdfcfedea020f50276286605e7fbb8@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Results are back: https://perf.haskell.org/ghc/#compare/54b9b064fc7960a4dbad387481bc3a6496cc397f/88dcbc63ae3482c55e96c12ab02ebc9a820781ff (not sure how stable that link is given that this is a rebasing branch) With only adding `length (takeWhile isOneShotInfo (occ_one_shots env))`, nofib allocations are stable. This suggests that this is a sane thing to do, i.e. we do not duplicate any work. Binary sizes go down by -0.7% throughout the bank, so there is relevant effect. We get a run-time performance loss in `binary-trees` by 9%. `binary-trees` benefited strongly from Join Point, so my blind guess is that in some instance here, floating out is beneficial as it turned something into a join point. Morally, the code is what we want (it makes the analysis more precise). I guess we should check out the performance fall out in `binary-tree`, though… You can have a look at the code at Phab:D3089. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 5 23:18:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Feb 2017 23:18:06 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.9be7b5a74d13e14b2032e93c4f1d4448@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | 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 sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 01:13:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 01:13:43 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.f33ab34c480d810bf28afe8cd311b4b0@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: dfeuer Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.3 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:D3038 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 01:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 01:16:54 -0000 Subject: [GHC] #13191: Make liftA2 a method of Applicative In-Reply-To: <045.6e3d12c3796dddf03258e755974fce1f@haskell.org> References: <045.6e3d12c3796dddf03258e755974fce1f@haskell.org> Message-ID: <060.1525adf506e3c012963e6ce8e6b57339@haskell.org> #13191: Make liftA2 a method of Applicative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3031 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 02:25:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 02:25:01 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.318ce247b3a55ecff7eb718694b441a9@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: T7102a, T7102 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2994 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0abe7361249b0b4dc43dc66547451da8916b30bf/ghc" 0abe7361/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0abe7361249b0b4dc43dc66547451da8916b30bf" Don't replace type family instances with the same LHS in GHCi (#7102) This fixes the easy part of #7102 by removing the logic that lets the user replace a type family instance with a new one with the same LHS. As discussed on that ticket, this is unsound in general. Better to have the user redefine the type family from scratch. The example from comment:7 involving loading modules into ghci is not fixed yet; it actually doesn't rely on the instances having the same LHS. This commit adds an expect_broken test for that example as well. Test Plan: T7102a for the fix; T7102 is the test not fixed yet Reviewers: dfeuer, austin, bgamari, goldfire Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2994 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 02:25:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 02:25:01 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.637403996520b33576d98ec5b39a8507@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"795bc49ceb12cecf46e0c53a570809c3df85ab9a/ghc" 795bc49c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="795bc49ceb12cecf46e0c53a570809c3df85ab9a" Fixes for OccurAnal bugs (#13221) - OccurAnal: When checking tail calls, count rule's LHS args, not bndrs Pretty obvious error in retrospect: ``` let $sj = \y ys -> ... {-# RULES "SC:j" forall y ys. j (y:ys) = $sj y ys #-} j = \xs -> ... in ... ``` A jump on the RHS of a rule for a join point is only okay if the rule's LHS is saturated - in this case, since the LHS is j (y:ys) and j takes one argument, both j and $sj can become join points. See Note [Rules and join points] in OccurAnal. By mistake, OccAnal was counting the rule's binders (y and ys) rather than the args in its LHS, so $sj wasn't being made a join point. - Don't zap tail calls in unfoldings This was causing T7796 to squeal about join points not being rediscovered. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3080 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 03:18:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 03:18:48 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.e8a2de5873b56b69eeedfe9c3daf2552@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by arybczak): * owner: => arybczak -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 03:55:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 03:55:52 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.97a27f6419518549cc0f91fda2ac2245@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3046 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This was committed as, {{{ commit b572aadb20c2e41e2f6d7b48401bd0b4239ce9f8 Author: Eric Seidel Date: Sun Feb 5 21:29:37 2017 -0500 Do Worker/Wrapper for NOINLINE things Disabling worker/wrapper for NOINLINE things can cause unnecessary reboxing of values. Consider {-# NOINLINE f #-} f :: Int -> a f x = error (show x) g :: Bool -> Bool -> Int -> Int g True True p = f p g False True p = p + 1 g b False p = g b True p the strictness analysis will discover f and g are strict, but because f has no wrapper, the worker for g will rebox p. So we get $wg x y p# = let p = I# p# in -- Yikes! Reboxing! case x of False -> case y of False -> $wg False True p# True -> +# p# 1# True -> case y of False -> $wg True True p# True -> case f p of { } g x y p = case p of (I# p#) -> $wg x y p# Now, in this case the reboxing will float into the True branch, an so the allocation will only happen on the error path. But it won't float inwards if there are multiple branches that call (f p), so the reboxing will happen on every call of g. Disaster. Solution: do worker/wrapper even on NOINLINE things; but move the NOINLINE pragma to the worker. Test Plan: make test TEST="13143" Reviewers: simonpj, bgamari, dfeuer, austin Reviewed By: simonpj, bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3046 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 03:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 03:57:00 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.9ffadc5ed0bc87f69be19a7546d3e023@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3090 Wiki Page: | -------------------------------------+------------------------------------- Changes (by arybczak): * differential: => D3090 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 03:59:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 03:59:17 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.8eabecef7244aaaecbdee220c033c22d@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3090 Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): Link to a fix: https://phabricator.haskell.org/D3090 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 04:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 04:14:16 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.1dc0cb2923b4d4940dfd3e6cc8f3adfc@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: Would it be possible to reimplement `runRW#` as a magic function with a compulsory unfolding, so that `runRW# f` expands to the following? {{{#!hs join $j s = f s {-# NOINLINE $j #-} in jump $j realWorld# }}} This would not only close this ticket but also allow other optimizations like pushing a `case` into the body of `f`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 05:02:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 05:02:11 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.dddd41764390fd36d5afdae32ba16f58@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 siddhanathan): Different implementations for different key types would be nice. Doing so would allow type specific optimizations, such as using judy arrays for string keys. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 05:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 05:18:28 -0000 Subject: [GHC] #13201: Type-level naturals aren't instantiated with GHCi debugger In-Reply-To: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> References: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> Message-ID: <058.7c9629fe9a1b410a000ee4708ed94e08@haskell.org> #13201: Type-level naturals aren't instantiated with GHCi debugger -------------------------------------+------------------------------------- Reporter: konn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: Here is a test case that doesn't use type-level naturals: {{{#!hs {-# LANGUAGE StandaloneDeriving #-} data Foo a = Foo deriving instance (Show a) => Show (Foo a) fooSucc :: Foo a -> Foo [a] fooSucc Foo = Foo foos :: Foo a -> [Foo [a]] foos f = loop 5 where loop 0 = [] loop n = fooSucc f : loop (n - 1) main :: IO () main = print $ foos (Foo :: Foo Int) }}} By no means I'm an export on this, but as far as I know, the GHCi debugger tries to re-construct the type information as much as possible by inspecting the runtime representation (closures) of the values. This means it cannot distinguish between different types with the exact same representation. For example, it cannot distinguish a newtype from its content type, nor can it determine a phantom type parameter of a data type. In this example, since `n` is only used as a phantom parameter of the datatype `Foo`, the GHCi debugger has no way of reconstructing it at runtime, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 08:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 08:07:05 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.8df52dd909bb01cbd5da230677477a7e@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3090 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: D3090 => Phab:D3090 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 09:04:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 09:04:51 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.778b68a43a64ab03deee11acc1c2d106@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I've rebased the [https://github.com/takano-akio/ghc/commits/nested-cpr branch] on top of the join points work. In nofib, allocations are generally down but the difference is not very big: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- bspt +0.0% +0.1% 0.007 0.007 0.0% compress2 +1.5% -0.9% 0.158 0.158 -3.7% fluid +1.6% -0.2% 0.007 0.007 0.0% infer +0.0% -1.2% 0.039 0.039 0.0% pic +0.1% -0.6% 0.005 0.005 0.0% solid +0.0% -6.6% 0.159 0.159 0.0% -------------------------------------------------------------------------------- Min -0.0% -6.6% -28.7% -28.8% -3.7% Max +1.6% +0.1% +4.3% +4.3% +6.7% Geometric Mean +0.1% -0.1% -14.7% -14.5% +0.0% }}} I'll look more carefully to see why the improvement is so small. I may have messed up something while rebasing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 13:16:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 13:16:46 -0000 Subject: [GHC] #13235: (makeVersion [4, 9, 0, 0] <= makeVersion [4, 9]) == False Message-ID: <045.f18c0597f6131f07169150ab71a03583@haskell.org> #13235: (makeVersion [4, 9, 0, 0] <= makeVersion [4, 9]) == False -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 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 hit a strange bug in cabal project. Zeroes in Version have meaning, which is not logical (at least mathematically). See this example: {{{ import Data.Version makeVersion [4, 9, 0, 0] <= makeVersion [4, 9] False }}} I propose to add zeroes to the version with less numbers, so they could be equally compared. Related discussion: https://github.com/commercialhaskell/stack/issues/2948 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 15:05:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 15:05:42 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.fb7d7a67ffb5de1694144b2d01fb2145@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just a warning: I am wary with exposing the `realWorld#` item here. I played with similar (less sophisticated) ideas three years ago, and found that all too easily different invocations of `runRW#` would end up getting mixed up, e.g. by CSE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 16:27:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 16:27:02 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.227004b15ebaee65736f37a7ba40d396@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Smaller example {{{ type family Open a type instance Open Int = Bool type family F a :: Open a type instance F Int = True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 17:19:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 17:19:46 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.d38a3dbd2851c05264fc5d141ca68aa4@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3046 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Hmm. I guess I am a bit late to the party, but I feel uneasy about this. On some level, to me, `NOINLINE` means “Dear compiler, in all uses of this, please treat this as a black box with precisely the interface I give here.” Allowing W/W moves a part of what the function does (e.g. taking a constructor apart) to the uses. I guess the test case did not come up with anything, but does this interfere with rules? A rule might mention the `NOINLINE` thing, but aftetr W/W, the worker remains, and a rule will no longer fire. `NOINLINE` is also very useful to prevent the compiler from optimizing test cases in our test suite too much (although I see that that should not be a driving factor). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 17:19:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 17:19:58 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.ad529391e27f2736765a0b4c62bf0721@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The nub of my idea in comment:13 and comment:15 is this: * Track dependency on ''declarations'' independently from ''definitions''. * When `T`'s declaration depends on `S`'s declaration, then `T`'s definition depends on `S`'s definition. * Dependency tracking is, as usual, transitive. So in the smaller example in comment:35, `F`'s declaration depends on `Open`'s. So `F`'s definition -- the instances -- depends on `Open`'s. This means we type check `Open`'s instances before `F`'s. There's lots more detail (comment:15) but this is the basic idea. Here is a case (due to Iavor) that would be rejected: {{{ type family Open a type instance Open Int = Bool type instance Open Char = F FLoat type instance Open Float = Type type family F a :: Open a type instance F Int = True type instance F Char = [True] type instance F Float = [Bool] }}} The instances for a given type family are checked as a clump, and these instances can be accepted only by interleaving. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 17:37:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 17:37:46 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories In-Reply-To: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> References: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> Message-ID: <064.77ff11f67fb1636bf0d353755e5c3670@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => closed * resolution: => invalid Comment: I actually have just realised that we don't bundle or ship `cpphs` at all. So this is unrelated to the toolchain. It's purely a user package issue as such I'll close this issue but will continue to monitor upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 18:11:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 18:11:39 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.0a80805460c266dd2f84e37fe3cc24eb@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Comment: So it seems that we somehow have an unsaturated application of `(#,#)` making it to `CoreToStg`. Usually saturated applications of a `DataConWorkId` will result in a `StgConApp`. However, since this isn't saturated we end up with an `StgApp`. More updates to come. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 18:15:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 18:15:48 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.3699e46ae539d0599e48cd822e9205a5@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like this binding from the Core Prep output is the culprit, {{{ -- RHS size: {terms: 8, types: 27, coercions: 0} StgCmmMonad.$fHasDynFlagsFCode2 :: StgCmmMonad.CgInfoDownwards -> StgCmmMonad.CgState -> (# StgCmmMonad.CgInfoDownwards, StgCmmMonad.CgState #) [GblId] StgCmmMonad.$fHasDynFlagsFCode2 = case \ (@ (k0_10 :: GHC.Types.RuntimeRep)) (@ (k1_11 :: GHC.Types.RuntimeRep)) (@ (a_12 :: TYPE k0)) (@ (b_13 :: TYPE k1)) -> GHC.Prim.(#,#) @ k0 @ k1 @ a @ b of sat_skkE { __DEFAULT -> sat_skkE @ 'GHC.Types.LiftedRep @ 'GHC.Types.LiftedRep @ StgCmmMonad.CgInfoDownwards @ StgCmmMonad.CgState } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 19:04:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 19:04:48 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.ddc55e8b39c19809d7d4e2bcc71e99ad@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): At this point I'm fairly convinced that this was introduced by the levity polymorphism work. While I'm still working out precisely what is going on, it seems that our conception of arity may be a bit inconsistent, meaning that we don't eta expand enough in CorePrep. One thing that surprised me is the type of the worker for `(#,#)`, {{{#!hs (#,#) :: forall (a :: TYPE k0) (b :: TYPE k1). a -> b -> (# a, b #) }}} In contrast I would have expected, {{{#!hs (#,#) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). a -> b -> (#,#) r1 r2 a b }}} That is, it seems to me like the worker is missing `RuntimeRep` arguments. Goldfire, am I missing something here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 19:33:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 19:33:33 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.2b10c2f56ac4ea9d4948d2164a088d9c@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, forget what I said in comment:8: I had neglected to pass `-fprint-explicit-runtime-reps`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 20:02:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 20:02:32 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.cdb8c73857af4fe4b3fa6fdb21e46a83@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Interesting... So we are calling (correctly) `cpeEtaExpand 2 (#,#)` yet somehow getting back, {{{#!hs \ (@ (k0_10 :: RuntimeRep)) (@ (k1_11 :: RuntimeRep)) (@ (a_12 :: TYPE k0)) (@ (b_13 :: TYPE k1)) -> (#,#) @ k0 @ k1 @ a @ b }}} Which most certainly does not have two value-level lambdas. Hmmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 20:20:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 20:20:44 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.b6fe9f83c6ed6fb199989843000a470b@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahhh, I see what is happening here. `CoreArity.mkEtaWW` is refusing to eta expand the value-level arguments of `(#,#)` as they are levity polymorphic, {{{#!hs | otherwise -- We have an expression of arity > 0, -- but its type isn't a function, or a binder -- is levity-polymorphic = WARN( True, (ppr orig_n <+> ppr orig_ty) $$ ppr orig_expr ) (getTCvInScope subst, reverse eis) }}} Had I been compiling with `DEBUG` this would have been plainly obvious but I was lazily merely building with `BuildFlavour=prof`. Serves me right, I suppose. Anyways, this is a little hairy. Indeed eta expanding here would be quite suspicious. Really, it seems like we never should have produced the lambda being scrutinised in comment:7 at all given that it is levity polymorphic. I'll have to look into where this is coming from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 20:27:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 20:27:14 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.7a29b8489ca13b3e32f5138f6508c817@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Interesting, the tidy core shows, {{{#!hs -- RHS size: {terms: 1, types: 4, coercions: 0} StgCmmMonad.$fHasDynFlagsFCode2 :: CgInfoDownwards -> CgState -> (# CgInfoDownwards, CgState #) [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 0 10}] StgCmmMonad.$fHasDynFlagsFCode2 = ghc-prim-0.5.0.0:GHC.Prim.(#,#) @ 'ghc-prim-0.5.0.0:GHC.Types.LiftedRep @ 'ghc-prim-0.5.0.0:GHC.Types.LiftedRep @ CgInfoDownwards @ CgState }}} Which we would have been able to eta expand without any trouble. It must be something in CorePrep that is gumming up the works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 21:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 21:01:31 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.1d8102f217b434206b4ee07d2761af9c@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You sound hot on the case. I agree with everything you've written here. Let me know if you need a boost over a crag somewhere! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 21:43:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 21:43:07 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.f233ab5ee2c61bf7f6b712b3670521a5@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahhh, here we have the issue. CorePrep is trying to prepare, {{{#!hs $fHasDynFlagsFCode2 :: CgInfoDownwards -> CgState -> (# CgInfoDownwards, CgState #) $fHasDynFlagsFCode2 = (tick (#,#)) @ 'LiftedRep @ 'LiftedRep @ CgInfoDownwards @ CgState }}} At first glance there is nothing particularly alarming about this. However, note the tick around `(#,#)`: this is quite bad since it cuts the `(#,#)` off from its `RuntimeRep` applications, making the whole expression appear much more polymorphic than it really is in `CorePrep.cpeApp`. Specifically, we first `collect_args` on the whole expression yielding, {{{#!hs collect_args (tick (#,#)) @'LiftedRep @'LiftedRep @CgInfoDownwards @CgState == (tick (#,#), [ CpeApp 'LiftedRep, CpeApp 'LiftedRep, CpeApp CgInfoDownwards, CpeApp CgState ] ) }}} `cpe_app` then looks at the `tick (#,#)` to decide what to do next. Specifically, it wants to see a plain `Var`, but that's not what we have. Consequently we end up recursing via `cpeArg`, which will be deprived of knowledge of the `RuntimeRep` type applications. It's difficult to say what the right solution here is. I have yet to look into how we end up with the tick scoping over only the constructor; it's possible that the tick was pushed in too far. More coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 21:50:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 21:50:17 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.00b5ccd7344c02d05a79c13709d9d613@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I do wonder whether `collect_args` is being too conservative here: it will only look through ticks where `tickishPlace tickish == PlaceNonLam && tickish `tickishScopesLike` SoftScope`. Even in the most restrictive tick placement type (`PlaceRuntime`) we allow ticks to be floated through type lambdas. Perhaps `collect_args` should continue to look through ticks, so long as there are no value-applications inside? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 21:51:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 21:51:02 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.42fc2d7fdbe21428f3eca93fea85d017@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Goldfire, it would be interesting to hear your opinion about the above two comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 22:05:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 22:05:12 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.062cfb6e6f3efd92512bac47a216c72d@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, after `FloatOut` we have, {{{#!hs getInfoDown :: FCode CgInfoDownwards getInfoDown = scctick $ @ 'LiftedRep @ (CgInfoDownwards -> CgState -> (# CgInfoDownwards, CgState #)) @ (FCode CgInfoDownwards) (lvl_shOy `cast` ...) (ghc-prim-0.5.0.0:GHC.Prim.(#,#) @ 'ghc-prim-0.5.0.0:GHC.Types.LiftedRep @ 'ghc-prim-0.5.0.0:GHC.Types.LiftedRep @ CgInfoDownwards @ CgState) lvl_shOy :: (CgInfoDownwards -> CgState -> (# CgInfoDownwards, CgState #)) -> CgInfoDownwards -> CgState -> (# CgInfoDownwards, CgState #) lvl_shOy = \x -> x }}} Which after simplification turns into, {{{#!hs getInfoDown_shTB :: CgInfoDownwards -> CgState -> (# CgInfoDownwards, CgState #) getInfoDown_shTB = (tick ghc-prim-0.5.0.0:GHC.Prim.(#,#)) @ 'ghc-prim-0.5.0.0:GHC.Types.LiftedRep @ 'ghc-prim-0.5.0.0:GHC.Types.LiftedRep @ CgInfoDownwards @ CgState }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 22:16:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 22:16:39 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.abbb2f81e246dbbfbcc885fcfd6f69f6@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In general all of this tick business is terribly fragile since there is no strong invariant (as far as I know) dictating where they might appear. I wonder if it would be reasonable a put inplace a Core invariant (checked by `CoreLint`) stating that "a tick must not sit directly inside of a type abstraction, type application, or cast. That is, we would normalize all things of the form, {{{ (tick e) @ty --> tick (e @ty) }}} It already seems like we try to do something along these lines, but it's not strongly checked. Does this make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 22:35:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 22:35:05 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.3e2bfb09fe5f3187707c67c4ad35b338@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, interesting... `CoreUtils.mkTick` actually does the exact opposite of what I suggest: it pushes ticks **into** type applications. This certainly explains my observations. Unfortunately there's no explanation given for why we want to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 22:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 22:39:33 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.8ecc59c73a65d0c4a23eb720c324931f@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:16 bgamari]: > Goldfire, it would be interesting to hear your opinion about the above two comments. I have no opinion. This area of the compiler is a mystery to me. That levity-polymorphism check you discovered earlier was put there only by Simon guiding my hand. It still sounds like you're on a brilliant chase, though... :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 22:54:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 22:54:08 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.26c218b1b74ab4c345b795604293a849@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Are you using any GHC primops, or functions with names that begin with `unsafe`? Those functions could easily corrupt the heap if misused. In particular, are you using `unsafeCoerce` anywhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 23:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 23:13:24 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.c6dcab8f5b0f96f7d4e7266af352369f@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar, scpmw (added) Comment: I strongly agree that we should write down the invariants for ticks, and check them in Lint. Sadly I do not know what they are. The only people who do are Simon Marlow and Peter Wortmann. I feel uneasy about the whole tick business being so ill-documented. Simon, Peter, can you help please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 23:41:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 23:41:47 -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.8f1c1a39d8e9e0e6df88da60cc8f4219@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Further clarifications > Currently in simplifyDeriv, we are using the function simplifyWantedsTcM to simplify the constraints, which seemed to work well back when all of our deriving-related constraints were simple wanteds. But now we're throwing implication constraints into the mix. Are you proposing to replace the use of simplifyWantedsTcM entirely with something la simplifyInfer? Are you proposing to invoke a simplifyInfer-like function after simplifyWantedsTcM? Something else? Something like `simplifyInfer`, but simpler. Call `simplifyWanteds`; then `approximateWC`; then `mkMinimalBySCs`; then emit the residual constraint as above. > 2. When you say "just emit this implication": `forall d. CX => RC`.. To tie it back to your example in comment:10, are you proposing to emit this? {{{ forall d. Show d => ((forall b. () => (Show d, C d b)) ^ (forall . Eq (Maybe d) => (Ord d, Show d)) }}} > That is, letting {{{ CX = (Show d) RC = ((forall b. () => (Show d, C d b)) ^ (forall . Eq (Maybe d) => (Ord d, Show d)) }}} Maybe you meant comment:14. Then yes. (There are several related examples in comment:14, so I'm not sure precisely which one you mean. > I see that there is a function emitImplication, which appears to modify the state of TcM. But I'm still unsure of when the error message involving (C d b) is supposed to be thrown. That is, what specific action causes the typechecker to see the bogus (C d b) and complain? It's the `simplifyTop` called right at the top level, in `TcRnDriver`. Most constraint solving is done by this single call to `simplifyTop`; only when we MUST solve eagerly (as here, to get CX) do we call the solver. Usually we just toss the unsolved constraint into the monad and solve it right at the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 6 23:52:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Feb 2017 23:52:27 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.b878493ca7d63d708b8672f2ff680efa@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3046 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I guess the test suite did not come up with anything, but does this interfere with rules? A rule might mention the NOINLINE thing, but aftetr W/W, the worker remains, and a rule will no longer fire. That's a worry for all functions; but the wrapper always get an inline activation that allows it to inline only in the last phase. See `Note [Wrapper activation]` in `WorkWrap`. What you say has merit; but it was bad bad bad before we made this change. If there's actually a problem with this new story, let's see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 00:02:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 00:02:45 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.8e94746d7006443e4f1c2af8c0c4fd71@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Cool idea though. See `Note [runRW magic]` in `MkId` for the main comment on this. I like the way that consumers correctly consume the result. We'd really like that NOINLINE to disapper right at the end somehow. One thing I like about `runRW#` is that it signals the magic very clearly; somehow a NOINLINE on a join point feels a bit too subtle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 00:18:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 00:18:45 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.dbcb046bcf6f682e6e632e1ec50d13d7@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed. Start with one or two poster-child examples to show what the goal is; and check they work as expected. Only then go in with nofib. Also this is a long ticket. It would be good to write a decription somewhere (on the wiki page?) of what exactly the patch does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 00:21:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 00:21:14 -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.91644cd13504af7bdc27f28e5e7b7956@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 simonpj): Just needs someone to pick up the cudgels. Volunteers welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 00:24:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 00:24:16 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.773924185cf8ef67f4fd8f68888d063d@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The remaining source of noise is beta redexes arising from the simple optimizer; that's an ongoing issue I'm working on that. Are there any other join points that occur-anal doesn't find? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 00:30:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 00:30:55 -0000 Subject: [GHC] #13216: internal error: stg_ap_pppppp_ret In-Reply-To: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> References: <045.19caace179f50142e99eb7bab0a10ceb@haskell.org> Message-ID: <060.1fb8eabfda1d09770453248ebd410138@haskell.org> #13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): No, no `unsafe` calls to anywhere.. (Unless one of the dependencies does; which I doubt.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 01:46:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 01:46:02 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.01f94e825ef75516147f9526bfae66ac@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): After a closer I don't think it's actually worth opening a separate ticket, as the optimizations the desugarer performs are truly simple. It's just 1. the dead code removal this ticket already aims to address, and 2. inlining single-use functions, which is also problematic for analysis tools (we may have annotated the function with some internal invariant!). As an example, {{{ foo :: Int -> Int foo x = g x where -- g is only used once so it is immediately inlined by -- CoreSubst.simple_opt_expr g y = y + 1 }}} Before `simpleOptPgm`: {{{ foo :: Int -> Int foo = \ (x :: Int) -> letrec { g :: Int -> Int g = letrec { g :: Int -> Int g = \ (y :: Int) -> + y 1; } in g; } in g x }}} After: {{{ foo :: Int -> Int foo = \ (x :: Int) -> (\ (y :: Int) -> + y 1) x }}} Granted, the nested definition of `g` pre-optimization is weird, but LiquidHaskell (at least) already handles this pattern without any special effort on our end. I think a cleaner solution would be my suggestion to move `simpleOptPgm` from the desugarer to an initial Core2Core pass (perhaps guarded by a flag so it doesn't bug regular users). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 01:51:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 01:51:34 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.9f3105a9d1f2db66f24f32ecf1b38a06@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): (I'm happy to implement my suggestion, it would also let me finish the languishing Phab:D1565 and remove the desugarer fork we use in LiquidHaskell) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 02:01:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 02:01:47 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.604f99e3729460faa1100ca08f25c484@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): (I would not object a different implementation, as long as it gets the job done; preferably without requiring the user to add any flags or annotations.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 05:18:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 05:18:08 -0000 Subject: [GHC] #13218: <$ is bad in derived functor instances In-Reply-To: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> References: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> Message-ID: <060.5ee3525e45f5442644533ce6d046a895@haskell.org> #13218: <$ is bad in derived functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: deriving-perf 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 David Feuer ): In [changeset:"2219c8cd612ec7920a3bd1661b3c663575737267/ghc" 2219c8c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2219c8cd612ec7920a3bd1661b3c663575737267" Derive <$ Using the default definition of `<$` for derived `Functor` instance is very bad for recursive data types. Derive the definition instead. Fixes #13218 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D3072 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 05:27:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 05:27:38 -0000 Subject: [GHC] #13218: <$ is bad in derived functor instances In-Reply-To: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> References: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> Message-ID: <060.3f0ac44a0f0ebcb8626dff9bd03a00e8@haskell.org> #13218: <$ is bad in derived functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: deriving-perf 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 dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 06:38:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 06:38:23 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.819885f035c81c0f0faffa61501f35e2@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3090 Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): While the patch is for 8.1, I adapted it for 8.0.2 (by basically adjusting MIN_VERSION_base to 4.9.1) and tested on Windows. It works fine, i.e. cabal using patched GHC was able to build dependencies for stack concurrently without failures (with -j8) a couple of times, whereas cabal using stock 8.0.1 failed every time with "permission denied" error during register phase of one of the packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 08:23:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 08:23:51 -0000 Subject: [GHC] #13214: Orphan instances in Backpack signatures don't work In-Reply-To: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> References: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> Message-ID: <060.c88d5d1f4608db3134f6497d23d2649f@haskell.org> #13214: Orphan instances in Backpack signatures don't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3095 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3095 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 08:44:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 08:44:31 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.adb6e25ebc766fee4521aafade905217@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: patch 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: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm getting lost here * First: > It would be nice if plugins could see a "faithful" representation of the source code I have no idea what that means, but by all means open a new feature request with a proposed design. * Second: should `simpleOptPgm` be a separate pass? The reason it's put in the back of the desugarer is not adequately documented. So it'd be worth a try if there is some benefit (what is the benefit?). You'd also need to ensure that Lint did not check the output of the desugarer, only the output of that first pass. `simpleOptPgm` really discards a LOT of junk sometimes! * Third, returning to the original question of the ticket, how can we keep all the binders alive in the output of `simpleOptPgm`? For that I like the approach you are taking in Phab:D3073; having a keep-alive set is nicer than messing with the guts of the analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 08:54:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 08:54:14 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.e9a7b1467219353667a5b963675102f7@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3046 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): As A GHC API user, I recognise my "primitives" by their name, so it is absolutely critical that they do not get inlined. If this new behaviour ever becomes a problem for me, would anyone be opposed to putting this behaviour behind a dynflag which is enabled by default whenever the W/W transformation is enabled, but can be disabled by GHC API users like me? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 08:58:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 08:58:49 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.0d1c4e61c27640c58baa53a1f8a3fd2a@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3046 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): darchon: The new behaviour here is only active when w/w happens, so what you want is already the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 10:02:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 10:02:32 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.822c544c3bc22826f69d15ededb02e5d@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, now that makes more sense. To flesh it out slightly: * The '''declaration''' `F:sig` of a type family `F` is its kind signature, e.g. {{{ type family F a :: * -> * }}} * The '''definition''' `F:def` of a type family `F` is the collection of all its type instances (in this module). e.g. {{{ type instance F Int = Maybe type instance F Bool = [] }}} For the purposes of this conversation we treat the instances for a single type family `F` as a single "clump"; they are always treated together. * Each '''vertex''' of the dependency graph is either * the declaration `F:sig` (i.e. kind signature) of a type family `F`, or * the definition `F:def` (i.e. type instances) of the type family. * If there is an '''edge''' in the graph from A to B, then A depends on B, and B must be type-checked before A. * The edges are as follows * An edge from `F:def` to `F:sig` * An edge from `F:sig` to `G:sig`, '''and from `F:def` to `G:def`,''' for any tycon `G` syntactically mentioned in `F`'s declaration * An edge from `F:def` to `G:def` for any tycon `G` syntactically mentioned in `G`'s definition. Now do strongly connected component analsis and process in order. Richard's magic is in the bold part of the second bullet. We could do with a proof of some kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 11:21:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 11:21:23 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.afdc5282a2ea49f632c858e3e3c7e710@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > With only adding length (takeWhile isOneShotInfo (occ_one_shots env)) Yes that's right. Sorry. If we commit this we need a serious Note. I like binary size decreases! It would be good to understand `binary_tree`; although I have no idea how to investigate runtime changes.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 11:47:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 11:47:24 -0000 Subject: [GHC] #13236: Improve floating for join points Message-ID: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> #13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having looked at the code in `SetLevels`, am very uncomfortable. My nose tells me that there is far too much chuffing about; it all makes my head spin. '''Question 1'''. Why do we ever "ruin" a join point? See {{{ Note [When to ruin a join point] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Generally, we protect join points zealously. However, there are two situations in which it can pay to promote a join point to a function: 1. If the join point has no value arguments, then floating it outward will make it a *thunk*, not a function, so we might get increased sharing. 2. If we float the join point all the way to the top level, it still won't be allocated, so the cost is much less. Refusing to lose a join point in either of these cases can be disastrous ---for instance, allocation in imaginary/x2n1 *triples* because $w$s^ becomes too big to inline, which prevents Float In from making a particular binding strictly demanded. }}} But I don't agree at all. If we have {{{ let-join j = e in b }}} then we can leave `j` in place as a join point. We can float `e` (via `lvlMFE`) if doing so would increase sharing. Indeed this applies uniformly to all join points. For example {{{ f x = let g y = let-join j z1 z2 = expensive x in case y of A p q -> j p q B r -> j r r C -> True }}} Here it would make sense to float `(expensive x)` out of the `\y` abstrction: {{{ f x = let lvl = expensive x g y = let-join j z1 z2 = lvl in case y of A p q -> j p q B r -> j r r C -> True }}} But doing so does not affect the join point `j`. Nullary join points are no different. This includes floating to the top level. Incidentally the RHS of the join point then becomes tiny, so the join point will be inlined. In short, I think we can just delete all this special code. '''Question 2''': `Note [Join points and MFEs]`. Whe do we ''ever'' float out a MFE that has a free join variable? SLPJ claim: if there is a free join variable, do not float it anywhere. '''Question 3''': Do we actually need to float join points ''at all''? Why? I thik the reason is just to make them small {{{ let-join j1 x = let-join j2 y = y+1 in ... }}} Here perhaps if we float `j2` out of `j1` that might make `j1` small enough to inline. But if that is the only motivation (unlike most of `FloatOut` which is about saving work) we'd better say so loud and clear. And the question is a bit more complicated; e.g. we might want to abstract over Ids to achieve this. e.g. {{{ let-join j1 x = let-join j2 y = x+y in ... ===> let-join j2' x y = x+y j1 x = let-join j2 y = j2' x y in ... }}} Now we can inline `j2`. (The example would be more realistic if the `x+y` was a big expression.) It's not just join parameters; we can abstract over any free variables: {{{ let-join j1 x = let p = x+y in let-join j2 z = p+z in .... }}} Here we could abstract `j2` over `p` in order to float it. It is not clear how best to do this; but I worry that we are asking `FloatOut` to do too much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 11:48:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 11:48:23 -0000 Subject: [GHC] #13236: Improve floating for join points In-Reply-To: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> References: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> Message-ID: <061.0317a98f789d6c6a71b28844dc602de7@haskell.org> #13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: lukemaurer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 13:50:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 13:50:26 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.456cd245b792245b902ca8354949f0b9@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Also, what about those haddock allocation regressions? Any idea what that could be about? Rather curious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 14:00:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 14:00:58 -0000 Subject: [GHC] #13144: FoatOut is not floating bottoming expressions properly In-Reply-To: <046.9f2c662c794331eaa161d287a4179fe3@haskell.org> References: <046.9f2c662c794331eaa161d287a4179fe3@haskell.org> Message-ID: <061.b62de1cbb184e54edf89a7907bcb3091@haskell.org> #13144: FoatOut is not floating bottoming expressions properly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a0174d2264358c5930a54e372d5d3ab5e713b87a/ghc" a0174d2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a0174d2264358c5930a54e372d5d3ab5e713b87a" Do not inline bottoming things If a function seems small, worker/wrapper won't split it; instead it turns it into an INLINE function. But if it's a /bottoming/ function that's a bad idea. We want don't want to inline bottoming functions unless they are /really/ small (smaller than the call itself) and that's handled by a different branch in certainlyWillInline. So this patch adds a not-bottom test to the UnfIfGoodArgs case of certainlyWillInline. No big perf effect, but this will tend to keep error code out of functions, and hence make them a bit more likely to inline. I fell over this when fiddling with #13144 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 14:50:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 14:50:04 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.c3fca7d2461ad399f3b45b07d4c50755@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 14:50:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 14:50:46 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.9e54ebcb129b4958c94fb84b0111d3a3@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will get finished up for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 15:02:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 15:02:58 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.a760670fac2d0ce745c747f8a02f2f0b@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): > But I think the real intent is ... No, not really. You'll see a lot of calls to `checkWiredInTyCon` whose solve purpose is to ensure that that the home module for the wired-in type constructor is loaded, even if you don't need to import the module to bring it into scope. In the example you give, > The literal [True] means GHC.Exts.fromListN 1 (True : []) OK, but `fromListN` is a known-key `Name` but it is not a wired-in `Id`. So to get `fromListN`'s type GHC is forced to load `GHC.Exts.hi`. So I don't see the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 16:20:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 16:20:16 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.2e56bffa569c8f207f8985ff59257023@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.11 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: #9939, #9973, | Differential Rev(s): Phab:D2498 #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"5ce39f6395efd81f9cc0e0aa2f36a7552ed75f7c/ghc" 5ce39f6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5ce39f6395efd81f9cc0e0aa2f36a7552ed75f7c" Add Wredundant-constraints to list of flags excluded from -Wall In light of #10635 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 18:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 18:41:32 -0000 Subject: [GHC] #13237: Extend TH with addModCStub Message-ID: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.0.1 Haskell | Keywords: inline-c | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- inline-c could benefit of the ability to tell the compiler to include some code in the object file of the current module. https://github.com/fpco/inline-c/issues/21 This way, a module `FFI.hs` using inline-c doesn't need to produce a file `FFI.c` with C code, but the code can be build and included in the file FFI.o directly. For this sake, it would be needed the following TH function: {{{ addModCStub :: String -> Q () }}} which would indicate to the compiler that the C code in the given string needs to be built and included in the object file of the current module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 18:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 18:43:36 -0000 Subject: [GHC] #13238: Harmonise pretty printing of parens in hsSyn Message-ID: <044.f41c6dada67f65332c2039335ba24d88@haskell.org> #13238: Harmonise pretty printing of parens in hsSyn -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Phab:D3043 Removes the insertion of parens in the pretty printer for `HsPar`. This is motivated by making it easier to see if there is a problem with the `ppr` round trip capability introduced in #3384. Due to a lack of time, the has not been done for `ParPat` or `HsParTy`. Complete this work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 19:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 19:24:20 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.eb0d23de601463ac352c97888e9f244c@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c 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 facundo.dominguez: @@ -6,2 +6,2 @@ - `FFI.c` with C code, but the code can be build and included in the file - FFI.o directly. + `FFI.c` with C code, but the code can be built and included in the file + object file of the module. New description: inline-c could benefit of the ability to tell the compiler to include some code in the object file of the current module. https://github.com/fpco/inline-c/issues/21 This way, a module `FFI.hs` using inline-c doesn't need to produce a file `FFI.c` with C code, but the code can be built and included in the file object file of the module. For this sake, it would be needed the following TH function: {{{ addModCStub :: String -> Q () }}} which would indicate to the compiler that the C code in the given string needs to be built and included in the object file of the current module. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 20:57:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 20:57:57 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.e344b4719a77f795fe4e5bc5ab6edb5f@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c 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 facundo.dominguez): * cc: simonpj, goldfire (added) * owner: => facundo.dominguez -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:21:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:21:51 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.241e09a511aed6ab163ad12e6fba50d5@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by dsc): * cc: dsc (added) Comment: (Not sure if my problem is different enough from this one to warrant a separate ticket.) I also have a problem where SpecConstr apparently gets stuck and doesn't converge to a fixed point: If I translate the Core back into Haskell and compile that again, I get great code with all state constructors eliminated. The code in question is TH-generated stream fusion code. I suppose that only the dump-splices result is relevant here, so I made it compilable and attached that (Input.hs). The Core (also attached) contains lots of seemingly obvious SpecConstr opportunities: {{{ test_$s$wgfold_loop = \ (sc :: FlattenState Int (ParamAndState Int (ConcatState YieldState () YieldState))) (sc1 :: Int) (sc2 :: Int#) -> case sc1 of _ [Occ=Dead] { I# y -> case sc of _ [Occ=Dead] { [...] Flatten_RunningInner so_agux si_aguy -> [...] test_$s$wgfold_loop (Flatten_RunningInner so_agux (ParamAndState a_aguz (CS_First AfterYielding))) a_aguz (+# (+# sc2 y) 42#); [...] test_$s$wgfold_loop (Flatten_RunningInner so_agux (ParamAndState a_aguz (CS_Second () AfterYielding))) a_aguz (+# (+# sc2 y) 42#) [...] }}} This is the second-round Core after retranslating the first Core into Haskell (hopefully without changing semantics) and compiling again: {{{ test_$s$wgfold_loop = \ (sc :: Int#) (sc1 :: Int#) (sc2 :: Int#) _ [Occ=Dead] _ [Occ=Dead] -> case tagToEnum# (># sc2 1000000#) of _ [Occ=Dead] { False -> test_$s$wgfold_loop (+# (+# (+# (+# sc sc1) 42#) sc2) 42#) sc2 (+# sc2 1#) sc2 (); True -> +# sc sc1 } }}} I noticed that in the first core, GHC thinks that `test_$s$wgfold_loop` is lazy (`Str=DmdType `). `-flate-dmd-anal` fixed that but doesn't seem to change much else (it unboxes one of the `Int` args, but doesn't affect the state type). I compiled with `stack ghc -- -O2 -ddump-simpl -ddump-to-file -dsuppress-module-prefixes -dsuppress-coercions -dsuppress-type-applications -dsuppress-uniques -dsuppress-unfoldings -fforce-recomp Input.hs` using GHC 8.0.1 (without `-dsuppress-uniques` for producing the TH splices). I also tried adding `-fmax-simplifier-iterations=999999 -fspec-constr- count=999999 -fspec-constr-threshold=999999 -fspec-constr-recursive=999999 -flate-dmd-anal -funfolding-use-threshold=999999` to no effect (the `-fspec-constr` flags are redundant since I'm using the `SPEC` type in the loop, correct?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:22:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:22:14 -0000 Subject: [GHC] #13239: Phabricator upgrade broke the ticket custom field Message-ID: <049.46dde039393aed4aa73448d64c0403c4@haskell.org> #13239: Phabricator upgrade broke the ticket custom field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- We have one custom field which should also appear in commit messages when running "arc diff". Since the upgrade on 07/02/2017, the field no longer appears when running "arc diff". The upgrade path is detailed in this upstream task. https://secure.phabricator.com/T12085 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:22:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:22:35 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.3e91968d1f38e3cbba3b1d6a3c39cfd5@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by dsc): * Attachment "Input.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:22:50 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.5b608bbae5be614698ce2e6b9b4ffb15@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by dsc): * Attachment "Input.dump-simpl" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:23:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:23:00 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.934351d34e1f57c4d62e6dd384f8b10b@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by dsc): * Attachment "ReHaskelledCore.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:23:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:23:10 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.187142f62a8781580bad5849655fb41e@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by dsc): * Attachment "ReHaskelledCore.dump-simpl" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 7 23:52:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Feb 2017 23:52:38 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.fdeb348766aaf728152c8b8b767b80b7@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 dsc): Just tried with GHC 8.0.2 and 7.10.3; similar problem. By the way, the original source looks like this: {{{ intersperseTest = $$(maybeSimplify $ S.enumFromToNum [|| 1 ||] [|| 1000000 :: Int ||] & S.concatMap (\a -> yield a S.++ yield a) & S.intersperse [|| 42 ||] & S.concatMap yield & S.sum_ & runIdentityE_static ) }}} (WIP library/experiment, trying for something like the [https://hackage.haskell.org/package/streaming streaming] package with robust fusion using typed TH :)) If I change the first `concatMap` to just `concatMap yield` or remove either the `intersperse` or the second `concatMap`, the problem is not present. I've had similar instances where the problem disappears after removing a random part of the pipeline (with that part fusing correctly if I remove a different part). Feels like I'm hitting some size limit rather than a fundamental problem (?) But as mentioned above, I already tried setting various GHC flags to large numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 00:07:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 00:07:51 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel Message-ID: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.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: -------------------------------------+------------------------------------- I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples: 1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. 2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific. 3. Only documentation files have changed. Building these on one platform should be sufficient. 4. A differential was closed by a commit. Only the most recent build will be useful, if that. It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 00:22:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 00:22:28 -0000 Subject: [GHC] #13241: Compile-time flag causing GC to zero evacuated memory Message-ID: <044.9c6eb4ff6ad59d2b238db78cee95de67@haskell.org> #13241: Compile-time flag causing GC to zero evacuated memory -------------------------------------+------------------------------------- Reporter: tommd | 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: -------------------------------------+------------------------------------- The `memory` package includes a `ScrubbedBytes` type that scrubs (zeros) the bytestring upon free via a finalizer. The intent with this type is to achieve a common requirement in the cryptographic world that key material is zeroed once it is no longer needed. Sadly, this technique is not useful for many reasons: * Consumers often take bytestrings * Key material often exists as other types such as bytestring, Text in case of passwords>>=KDF, or Integer in the case of home-grown RSA operations. * Scrubbing via a finalizer is clumsy, verbose, and error prone. `memory`'s scrubbing appears to be related to or even have caused a bug with a related library a while back. Note I am rather keen on _not_ arguing about the suitability of Haskell for cryptographic purposes. That's an orthogonal topic to the value of zeroing freed memory. I would like GHC to include a flag (`--zero-evacuated`?) that will cause evacuated memory to be zeroed by the GC. This functionality already exists as a debugging feature to help recognize unused (or misused) memory so I anticipate the actual RTS code change to be minimal. The main question is if GHCHQ agrees this feature is valuable enough to include another flag. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 00:25:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 00:25:53 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification Message-ID: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | 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: -------------------------------------+------------------------------------- {{{#!hs -- Panic.hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE ExistentialQuantification #-} module Panic where import Data.STRef import Control.Monad.ST data A = forall a. A a st :: ST s () st = do A _ <- pure $ A True ref <- newSTRef 1 readSTRef ref pure () }}} {{{ $ ghc Panic.hs [1 of 1] Compiling Panic ( Panic.hs, Panic.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): StgCmmEnv: variable not found $dMonad_aGQ local binds for: $trModule $tcA $tc'A $tcA1_rSi $tc'A1_rSJ $trModule1_rSK $trModule2_rSL sat_sT5 sat_sT9 sat_sTa Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:137:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The above module fails to compile, giving the pasted panic message. Without the ApplicativeDo pragma compilation succeeds. Reproduced with GHC 8.0.2 and a recent head, courtesy of nixpkgs: {{{ gp84vpgar3n3rqvkwj47yyhxvsvbsmi6-ghc-8.1.20170106 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 08:20:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 08:20:42 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel In-Reply-To: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> References: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> Message-ID: <060.204667b51a6270bde32b5617eee0e91a@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): 3. could be implemented using a herald rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 08:39:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 08:39:07 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.3e6a185ccf255126729386c234ae53d2@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * owner: => simonmar Comment: Simon M: this is an outright bug somewhere in `ApplicativeDo`. Using `-dcore-lint` nails it immediately in the output of the desugarer: {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: >>= @ (ST s) $dMonad_aRm @ (STRef s Integer) @ () (newSTRef @ Integer @ s 1) (\ (ref_aFs :: STRef s Integer) -> >> @ (ST s) $dMonad_a12S @ Integer @ () (readSTRef @ s @ Integer ref_aFs) (return @ (ST s) $dMonad_a131 @ () ())) $dMonad_aRm :: Monad m_aRl[tau:3] [LclId] is out of scope : warning: In the expression: >>= @ (ST s) $dMonad_aRm @ (STRef s Integer) @ () (newSTRef @ Integer @ s 1) (\ (ref_aFs :: STRef s Integer) -> >> @ (ST s) $dMonad_a12S @ Integer @ () (readSTRef @ s @ Integer ref_aFs) (return @ (ST s) $dMonad_a131 @ () ())) Argument value doesn't match argument type: Fun type: Monad (ST s) => forall a b. ST s a -> (a -> ST s b) -> ST s b Arg type: Monad m_aRl[tau:3] Arg: $dMonad_aRm *** Offending Program *** Rec { $tcA :: TyCon [LclIdX] $tcA = TyCon 4740327979976134328## 15826189822472469109## $trModule (TrNameS "A"#) $tc'A :: TyCon [LclIdX] $tc'A = TyCon 9840332441209672147## 16375955839481284679## $trModule (TrNameS "'A"#) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T13242"#) st :: forall s. ST s () [LclIdX] st = \ (@ s_aQu) -> let { $dApplicative_aR0 :: Applicative (ST s) [LclId] $dApplicative_aR0 = $fApplicativeST @ s } in let { $dApplicative_aR7 :: Applicative (ST s) [LclId] $dApplicative_aR7 = $dApplicative_aR0 } in let { $dFunctor_aQK :: Functor (ST s) [LclId] $dFunctor_aQK = $fFunctorST @ s } in <*> @ (ST s) $dApplicative_aR0 @ () @ () (fmap @ (ST s) $dFunctor_aQK @ A @ (() -> ()) (\ (ds_d13u :: A) (ds_d13v :: ()) -> case ds_d13u of wild_00 { A @ a_aRa ds_d13w -> let { $dNum_a12O :: Num Integer [LclId] $dNum_a12O = $fNumInteger } in let { $dMonad_aRm :: Monad (ST s) [LclId] $dMonad_aRm = $fMonadST @ s } in let { $dMonad_a12S :: Monad (ST s) [LclId] $dMonad_a12S = $dMonad_aRm } in let { $dMonad_a131 :: Monad (ST s) [LclId] $dMonad_a131 = $dMonad_aRm } in let { ds_d13x :: () [LclId] ds_d13x = ds_d13v } in case ds_d13x of wild_00 { () -> () } }) ($ @ 'LiftedRep @ A @ (ST s A) (pure @ (ST s) $dApplicative_aR7 @ A) (A @ Bool True))) (>>= @ (ST s) $dMonad_aRm @ (STRef s Integer) @ () (newSTRef @ Integer @ s 1) (\ (ref_aFs :: STRef s Integer) -> >> @ (ST s) $dMonad_a12S @ Integer @ () (readSTRef @ s @ Integer ref_aFs) (return @ (ST s) $dMonad_a131 @ () ()))) end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 08:39:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 08:39:22 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.f4f792df540e3a06fbe791df2bf681db@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 09:41:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 09:41:57 -0000 Subject: [GHC] #13239: Phabricator upgrade broke the ticket custom field In-Reply-To: <049.46dde039393aed4aa73448d64c0403c4@haskell.org> References: <049.46dde039393aed4aa73448d64c0403c4@haskell.org> Message-ID: <064.03d187bffb7a63c2a43de12114a7e3fe@haskell.org> #13239: Phabricator upgrade broke the ticket custom field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high Comment: Bumping the priority as this is also affecting `arc land` so the ticket information is not included in commit messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 09:44:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 09:44:40 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.afef16dac34c1ec0324a28dd341121c1@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * owner: => darchon * testcase: => T11525 * differential: => D3105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 09:45:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 09:45:30 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.b1042fccc982cc7b396dce7de1e67f13@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D3105 -------------------------------------+------------------------------------- Changes (by darchon): * differential: D3105 => https://phabricator.haskell.org/D3105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 09:46:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 09:46:18 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.0a0cbde5094df9a3d8b7e67e3f10d07b@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: https://phabricator.haskell.org/D3105 => Phab:D3105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 11:26:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 11:26:43 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.6bfff30ea3d964606b22fface2ee19bd@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 simonpj): I had a look. There are two things. '''Problem 1'''. With the grotesque (GHC's fault not yours) `SPEC` argument to force specialisation, GHC does not want to generate an infinite number of specialisations; e.g. {{{ f (a:b) = f (a::b) ... }}} This is limited by the (probably un-documented) flag `-fspec-constr- recurisive=N` flag. Its default value is far too low: 3. Set it to 20. The relevant bit in `SpecConstr` is {{{ is_too_recursive :: ScEnv -> (CallPat, ValueEnv) -> Bool -- Count the number of recursive constructors in a call pattern, -- filter out if there are more than the maximum. -- This is only necessary if ForceSpecConstr is in effect: -- otherwise specConstrCount will cause specialisation to terminate. -- See Note [Limit recursive specialisation] -- TODO: make me more accurate }}} And indeed it simply counts data constructors, not even recursive ones. That will seriously limit specialisation in precisely the case where you wanted a lot! At least we could count nesting depth rather than just counting constructors in total. '''Problem 2'''. Your code has {{{ (InterspersesState_Running (snd stored_fs_aguH)) }}} That use of `snd` is fatal, because it's not inlined before `SpecConstr` (since it is applied to an uninformative variable). So `SpecConstr` doesn't "see" the case inside `snd` and that means it generate too few specialisations. If you instead write {{{ -- InterspersesState_YieldedInterspersee stored_fs_aguH InterspersesState_YieldedInterspersee (fs1,fs2) -> gfold_loop sPEC_aguh acc_agui (Flatten_RunningInner -- (InterspersesState_Running (snd stored_fs_aguH)) (InterspersesState_Running fs2) -- (ParamAndState (fst stored_fs_aguH) BeforeYielding)) (ParamAndState fs1 BeforeYielding)) }}} where the old line is commented out, and replaced by the line below, then good things happen, and a single run gives {{{ Rec { -- RHS size: {terms: 33, types: 6, coercions: 0, joins: 0/0} Input.test_$s$wgfold_loop [Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# -> Int# [GblId, Arity=4, Caf=NoCafRefs, Str=] Input.test_$s$wgfold_loop = \ (sc_s5hq :: Int#) (sc1_s5hr :: Int#) (sc2_s5hs :: Int#) (sc3_s5hp :: Int#) -> case tagToEnum# @ Bool (># sc_s5hq 1000000#) of { False -> Input.test_$s$wgfold_loop (+# sc_s5hq 1#) sc_s5hq sc_s5hq (+# (+# (+# (+# sc3_s5hp sc2_s5hs) 42#) sc1_s5hr) 42#); True -> +# (+# (+# sc3_s5hp sc2_s5hs) 42#) sc1_s5hr } end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 11:41:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 11:41:05 -0000 Subject: [GHC] #13144: FoatOut is not floating bottoming expressions properly In-Reply-To: <046.9f2c662c794331eaa161d287a4179fe3@haskell.org> References: <046.9f2c662c794331eaa161d287a4179fe3@haskell.org> Message-ID: <061.23828638eb81e503df0cfa3e094f2f8b@haskell.org> #13144: FoatOut is not floating bottoming expressions properly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: 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 Wed Feb 8 12:04:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 12:04:12 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.3dbbbf4694b9136ab1fbc8b308042cb5@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You have realised that the spec in comment:12 can be further simplified (without changing its meaning): Find all the unsolved constraints. Then: * Find those that are of form `(C a)` where `a` is a type variable, and partition those constraints into groups that share a common type variable `a`. * Keep only the groups in which at least one of the classes is an interactive class. * Now, for each remaining group G, try each type `ty` from the default- type list in turn; if setting `a = ty` would allow the constraints in G to be completely solved. If so, default `a` to `ty`. Note that any multi-parameter constraints `(D a b)` or `(D [a] Int)` do not participate in the process (either to help or to hinder); but they must of course be soluble once the defaulting process is complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 12:24:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 12:24:51 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.4f6223fb8117ff4637f53c1a86627569@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D3106 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 12:25:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 12:25:32 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.0c56c909ff0c8788fd511dbf1a0b18ef@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -6,2 +6,2 @@ - `FFI.c` with C code, but the code can be built and included in the file - object file of the module. + `FFI.c` with C code, but the code can be built and included in the object + file of the module. New description: inline-c could benefit of the ability to tell the compiler to include some code in the object file of the current module. https://github.com/fpco/inline-c/issues/21 This way, a module `FFI.hs` using inline-c doesn't need to produce a file `FFI.c` with C code, but the code can be built and included in the object file of the module. For this sake, it would be needed the following TH function: {{{ addModCStub :: String -> Q () }}} which would indicate to the compiler that the C code in the given string needs to be built and included in the object file of the current module. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 12:29:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 12:29:21 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.9be036b0b51d4c9d7ad480f11dd70a88@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): On Phab you comment that this program is still rejected with ambiguous variables. {{{ {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module T12924 where import GHC.TypeLits data A (b :: [Symbol]) = A deriving Show class Works a (b :: [Symbol]) where works :: a -> A b instance Works Integer a where works _ = A addA :: A a -> A a -> A a addA A A = A test2 :: A x test2 = addA (works 5) (works 5) }}} The reason is described in `Note [ApproximateWC]` in `TcSimplify`, item (2) in that note. It arose from Trac #8155. We have a constraint {{{ forall x. () => Num alpha, Works alpha x }}} but because we carefully make the `Works alpha x` prevent the `Num alpha` float out for defaulting, for reasons described in the Note. The rule is un-documented and indeed hard to explain. I'm quite inclined to back-pedal on the fix to #8155. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 12:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 12:29:43 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.759746daedb07075c83544a61b041c98@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: you can go ahead with adding the user documentation for your patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 12:33:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 12:33:00 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation In-Reply-To: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> References: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> Message-ID: <064.557160c5a294b7a57d2371234df5e73b@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template | haskell, recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lippling): I seem to have a similar bug (with 8.0.2) in a Yesod app (the app compiles fine with 7.10.3): {{{#!hs [61 of 61] Compiling Application ( Application.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/Application.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/1q/4xcpgs9n52sf2j5wbhxlt3r40000gn/T/ghc1009_0/libghc_264.dylib, 5): Symbol not found: _opaleyezm0zi5zi2zi2zm8brufdPJKpl4nCQHKm9Oif_OpaleyeziInternalziRunQuery_zdfQueryRunnerColumnDefaultPGRangePGRange_closure Referenced from: /var/folders/1q/4xcpgs9n52sf2j5wbhxlt3r40000gn/T/ghc1009_0/libghc_264.dylib Expected in: flat namespace in /var/folders/1q/4xcpgs9n52sf2j5wbhxlt3r40000gn/T/ghc1009_0/libghc_264.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 Feb 8 15:12:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:12:45 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm In-Reply-To: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> References: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> Message-ID: <064.8e31f6410aca843c7a5747d73528a5b4@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints Comment: Done! {{{ commit 8e9593fb2147252ecb8b685ef6bf9c0237a71219 Author: Simon Peyton Jones Date: Tue Feb 7 00:32:43 2017 +0000 Improve the simple optimiser The previous version of the simple optimiser would leave beta-redexes, which was bad for join points. E.g. join j x = .... -- a join point in (\x. j x) y This would be ok if we beta-reduced the (\x) but not if we don't. This patch improves the simple optimiser, to follow the plan described in "Secrets of the GHC inliner", and implemented in the Mighty Simplifier. It turns out not to be too hard to use the same plan here, and we get slightly better code as a result. }}} Luke, you say: > The simpleOptPgm β-redexes are the only reason for the special rule in Core Lint (see Note [Beta redexes] in CoreLint.hs), so once this is done we can be rid of that. but don't we sometimes generate some beta-redexes in worker/wrapper after strictness analysis? I have not yet changed this. Adding keyword `JoinPoints` so we don't lose track of this. It'd be cool to finish it off. Ideally getting rid of type-lets too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 15:26:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:26:13 -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.4207e09f3ee4cd6c2a2b457d003982b5@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3eb737ee3f900f256a7474b199a4ab40178a8cac/ghc" 3eb737e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3eb737ee3f900f256a7474b199a4ab40178a8cac" Generalize CmmUnwind and pass unwind information through NCG As discussed in D1532, Trac Trac #11337, and Trac Trac #11338, the stack unwinding information produced by GHC is currently quite approximate. Essentially we assume that register values do not change at all within a basic block. While this is somewhat true in normal Haskell code, blocks containing foreign calls often break this assumption. This results in unreliable call stacks, especially in the code containing foreign calls. This is worse than it sounds as unreliable unwinding information can at times result in segmentation faults. This patch set attempts to improve this situation by tracking unwinding information with finer granularity. By dispensing with the assumption of one unwinding table per block, we allow the compiler to accurately represent the areas surrounding foreign calls. Towards this end we generalize the representation of unwind information in the backend in three ways, * Multiple CmmUnwind nodes can occur per block * CmmUnwind nodes can now carry unwind information for multiple registers (while not strictly necessary; this makes emitting unwinding information a bit more convenient in the compiler) * The NCG backend is given an opportunity to modify the unwinding records since it may need to make adjustments due to, for instance, native calling convention requirements for foreign calls (see #11353). This sets the stage for resolving #11337 and #11338. Test Plan: Validate Reviewers: scpmw, simonmar, austin, erikd Subscribers: qnikst, thomie Differential Revision: https://phabricator.haskell.org/D2741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 15:26:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:26:14 -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.cb8ee1b9f22f09ed9c7b506a45c1df07@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11337, #11353 | Differential Rev(s): Phab:D2743 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3eb737ee3f900f256a7474b199a4ab40178a8cac/ghc" 3eb737e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3eb737ee3f900f256a7474b199a4ab40178a8cac" Generalize CmmUnwind and pass unwind information through NCG As discussed in D1532, Trac Trac #11337, and Trac Trac #11338, the stack unwinding information produced by GHC is currently quite approximate. Essentially we assume that register values do not change at all within a basic block. While this is somewhat true in normal Haskell code, blocks containing foreign calls often break this assumption. This results in unreliable call stacks, especially in the code containing foreign calls. This is worse than it sounds as unreliable unwinding information can at times result in segmentation faults. This patch set attempts to improve this situation by tracking unwinding information with finer granularity. By dispensing with the assumption of one unwinding table per block, we allow the compiler to accurately represent the areas surrounding foreign calls. Towards this end we generalize the representation of unwind information in the backend in three ways, * Multiple CmmUnwind nodes can occur per block * CmmUnwind nodes can now carry unwind information for multiple registers (while not strictly necessary; this makes emitting unwinding information a bit more convenient in the compiler) * The NCG backend is given an opportunity to modify the unwinding records since it may need to make adjustments due to, for instance, native calling convention requirements for foreign calls (see #11353). This sets the stage for resolving #11337 and #11338. Test Plan: Validate Reviewers: scpmw, simonmar, austin, erikd Subscribers: qnikst, thomie Differential Revision: https://phabricator.haskell.org/D2741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 15:26:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:26:14 -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.94de192b7fa1e3aa6aa556a3397332dd@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3eb737ee3f900f256a7474b199a4ab40178a8cac/ghc" 3eb737e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3eb737ee3f900f256a7474b199a4ab40178a8cac" Generalize CmmUnwind and pass unwind information through NCG As discussed in D1532, Trac Trac #11337, and Trac Trac #11338, the stack unwinding information produced by GHC is currently quite approximate. Essentially we assume that register values do not change at all within a basic block. While this is somewhat true in normal Haskell code, blocks containing foreign calls often break this assumption. This results in unreliable call stacks, especially in the code containing foreign calls. This is worse than it sounds as unreliable unwinding information can at times result in segmentation faults. This patch set attempts to improve this situation by tracking unwinding information with finer granularity. By dispensing with the assumption of one unwinding table per block, we allow the compiler to accurately represent the areas surrounding foreign calls. Towards this end we generalize the representation of unwind information in the backend in three ways, * Multiple CmmUnwind nodes can occur per block * CmmUnwind nodes can now carry unwind information for multiple registers (while not strictly necessary; this makes emitting unwinding information a bit more convenient in the compiler) * The NCG backend is given an opportunity to modify the unwinding records since it may need to make adjustments due to, for instance, native calling convention requirements for foreign calls (see #11353). This sets the stage for resolving #11337 and #11338. Test Plan: Validate Reviewers: scpmw, simonmar, austin, erikd Subscribers: qnikst, thomie Differential Revision: https://phabricator.haskell.org/D2741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 15:40:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:40:11 -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.72e938901a17422f41fbdba481d40a26@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | 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 Feb 8 15:40:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:40:54 -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.1b13dd62e4125c65b6f7969ebf6eb5ca@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 15:41:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 15:41:04 -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.dd2040fa8c49c68a664af491cf9fa54b@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 16:08:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 16:08:17 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.a8cbb561da93e57cfda59ef606409c9c@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Turns out that back-pedaling on #8155 doesn't break #8155! So I'm going to do that. It's no documented feature, and it'll make more programs do defaulting. That leaves your tiny patch. It is no so small, and so well defined, that I think we should go ahead. Please do the user manual stuff and then we can land it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:01:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:01:39 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.813a0f0a050e25e55164db9e6827eece@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): Let me try to explain the situation with `OverloadedLists` more clearly. I'm just going to talk about the ''class'' instances since there is already something subtle going on there. Say that a class instance is * ''loaded'' if we have read the interface file that contains it; in this case into the EPS. I don't think it makes a real difference here, so I'll always assume we are talking about instances defined in external packages. * ''transitively imported'' from the module `M` that we're compiling if `M` imports (directly or indirectly) the module `D` that defines the class instance in question. * ''visible'' in the module `M` that we're compiling if we are allowed to use the instance to solve a constraint while compiling `M`. Clearly an instance must be loaded in order to be visible, but otherwise it's our job to implement the test for visibility so that it corresponds to the semantics that we want. The Haskell Report says > Thus, an instance declaration is in scope if and only if a chain of `import` declarations leads to the module containing the instance declaration. so we could simply define 1. A class instance is visible if and only if it is transitively imported. However, GHC's implementation is actually 2. A class instance is visible if and only if ''either'' it is transitively imported, ''or'' it is a non-orphan instance: it mentions something (a class or type) in the instance head that is defined in the same module. The intention is that definition 2 is equivalent to definition 1, but cheaper to compute as we don't have to carry around a larger set of all transitively imported modules, and don't have to do a membership query in this set in the common case of a candidate matching instance that is non- orphan. See `Note [Instance lookup and orphan instances]`: {{{ Suppose we are compiling a module M, and we have a zillion packages loaded, and we are looking up an instance for C (T W). If we find a match in module 'X' from package 'p', should be "in scope"; that is, is p:X in the transitive closure of modules imported from M? The difficulty is that the "zillion packages" might include ones loaded through earlier invocations of the GHC API, or earlier module loads in GHCi. They might not be in the dependencies of M itself; and if not, the instances in them should not be visible. Trac #2182, #8427. There are two cases: * If the instance is *not an orphan*, then module X defines C, T, or W. And in order for those types to be involved in typechecking M, it must be that X is in the transitive closure of M's imports. So we can use the instance. * If the instance *is an orphan*, the above reasoning does not apply. So we keep track of the set of orphan modules transitively below M; this is the ie_visible field of InstEnvs, of type VisibleOrphanModules. If module p:X is in this set, then we can use the instance, otherwise we can't. }}} Now, here's what happens in the situation with `OverloadedLists`. With this extension enabled, a list literal `[True]` desugars to a function call `fromListN 1 (True : [])`, where the `[]` in the desugaring is the constructor of the list type. I call this desugaring, but the reference to `fromListN` is really inserted in the renamer (`rnExpr (ExplicitList _ _ exps) = ...`). `fromListN` is a method of the class `IsList`, which is defined in `GHC.Exts`: {{{#!hs class IsList l where type Item l fromList :: [Item l] -> l fromListN :: Int -> [Item l] -> l -- the Int is the length of the list fromListN _ = fromList toList :: l -> [Item l] }}} The instance for `[a]` is also defined in `GHC.Exts`: {{{#!hs instance IsList [a] where type (Item [a]) = a fromList = id toList = id }}} Crucially `GHC.Exts` is ''not'' transitively imported by `Prelude`; so typically it will not be transitively imported in a module that uses `OverloadedLists`. (You can verify this easily since `GHC.Exts` defines instances of the type family `Item`, and it doesn't show up as a family instance import of a module that only imports `Prelude`. But remember this whole comment is about class instances, not family instances.) So suppose we want to type check the program {{{#!hs {-# LANGUAGE OverloadedLists #-} module Ol where f :: [Bool] f = [True] }}} It means {{{#!hs f :: [Bool] f = GHC.Exts.fromListN 1 (True : []) }}} and recall {{{#!hs fromListN :: IsList l => Int -> [Item l] -> l }}} So in order to type check `f`, we need to use the instance `IsList [a]`. (Let's ignore the issue of knowing that `Item [a] ~ a`, since this comment is not about family instance visibility.) The instance `IsList [a]` will certainly have been loaded, because we read the interface file for `GHC.Exts` in order to find out the type for `fromListN`. Now, consider our definitions 1 and 2 of class instance visibility. According to definition 1, the instance `IsList [a]` ''should not'' be visible because the module `GHC.Exts` in which it is defined is not transitively imported by the module we are compiling. However, the instance `IsList [a]` is not an orphan! So according to definition 2, the instance ''is'' visible. The upshot is that GHC treats the instance as visible and accepts the program, which is certainly the desired end result; but a strict interpretation of the standard says that GHC should reject the program, given the way that the `IsList` class is implemented. The problem is with this sentence from the Note quoted above: > And in order for those types [here `IsList`] to be involved in typechecking M, it must be that X is in the transitive closure of M's imports. It's not true in this example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:09:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:09:34 -0000 Subject: [GHC] #8155: Defaulting bug or unfortunate error message with closed type families In-Reply-To: <042.d1fffb3b5fccd3599843da11ae2f3067@haskell.org> References: <042.d1fffb3b5fccd3599843da11ae2f3067@haskell.org> Message-ID: <057.6fc099b8eeff1a29cc9f36eb25003af6@haskell.org> #8155: Defaulting bug or unfortunate error message with closed type families --------------------------+------------------------------------------------ Reporter: nh2 | Owner: Type: bug | Status: closed Priority: | Milestone: normal | Component: | Version: 7.6.3 Compiler | Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: | Test Case: indexed_types/should_fail/T8155 None/Unknown | Blocked By: | Blocking: Related Tickets: | --------------------------+------------------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"a94b484715d3caf445a7069377d5311e0e50f66e/ghc" a94b4847/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a94b484715d3caf445a7069377d5311e0e50f66e" Back-pedal the fix for Trac #8155 I implemented a rather elaborate fix for #8155 ages ago, which which turns out to be a) unnecesssary in this particular case b) harmful to the defaulting story; see comment:15 of #12923. So this patch reverts the elaborate bit. The bit I removed is described in "Historical note" under Note [approximateWC]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:09:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:09:34 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.07dd2850c0663303ac69bc84a21e9afe@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a94b484715d3caf445a7069377d5311e0e50f66e/ghc" a94b4847/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a94b484715d3caf445a7069377d5311e0e50f66e" Back-pedal the fix for Trac #8155 I implemented a rather elaborate fix for #8155 ages ago, which which turns out to be a) unnecesssary in this particular case b) harmful to the defaulting story; see comment:15 of #12923. So this patch reverts the elaborate bit. The bit I removed is described in "Historical note" under Note [approximateWC]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:09:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:09:34 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.43a63bcffbfb4bc841dcf7328b0f79ef@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3065, Wiki Page: | Phab:D3064 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3cfef763ab6ccd23f72604e5ee2f027a4b6ce043/ghc" 3cfef763/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cfef763ab6ccd23f72604e5ee2f027a4b6ce043" Kill inaccessible-branch complaints in record update Trac #12957 (the original case in the Description) showed a record update that yielded an "inaccessible code" warning. This should not happen; it's just some redundant code generated by the desugarer (later pruned away) and it's not the user's fault. This patch suppresses the warning. See Check.hs Note [Inaccessible warnings for record updates] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:11:26 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.fb5cb736ce8965d90bf68eb062c2a3c7@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:18:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:18:51 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.f914bb26a062a531d45b7ff968b508c3@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): To clarify the context, a solution to this feature would lift a long standing usability problem for inline-c. That package generates C code, which then has to be linked with all the other object code from a project. Since GHC doesn't know about this, we have to lie to Cabal by listing the generated C file as an extra source file. But that's a very gross hack. Only meant to work around the fact that GHC has no direct support for appending arbitrary object code to the output of the current compilation unit. But in essence, what inline-c is doing is no different from what GHC already needs to do in when compiling modules with foreign exports or foreign import wrappers: it creates C stubs whose object code must be included with the rest of the object code for the module. There are now at least a dozen open source libraries that depend on inline-c, and likely many more closed source ones. But the current hack explained above causes problems: listing a generated file as a source file tends to confuse GHC's and Stack's recompilation checking. Worse, in some cases the generated C source file causes the build to fail. More details here: https://github.com/fpco/inline-c/issues/21. Being able to programmatically register C stubs in the current compilation unit would solve both problems at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:20:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:20:02 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.60ea55b1a4beedcb84e3a5227280aeb4@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #11348, #12239 => #11348, #12239, #12643 Comment: When fixed, look at #12643 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:21:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:21:35 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.676c707896e1b6f9d84dd75f30ee743d@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: #12780 | Differential Rev(s): Phab:D3105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #12780 Comment: When this is done, revisit #12780 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:28:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:28:31 -0000 Subject: [GHC] #13077: Worker/wrapper can break the let-app invariant In-Reply-To: <046.dd2b4321fc316e147387f0f8a9549c64@haskell.org> References: <046.dd2b4321fc316e147387f0f8a9549c64@haskell.org> Message-ID: <061.1fcbf48f6dc6a449dd86ca390639d038@haskell.org> #13077: Worker/wrapper can break the let-app invariant -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_compile/T13077, | T13077a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => stranal/should_compile/T13077, T13077a * resolution: => fixed Comment: Fixed by {{{ commit 596dece7866006d699969f775fd97bd306aad85b Author: Simon Peyton Jones Date: Fri Jan 13 08:56:53 2017 +0000 Record evaluated-ness on workers and wrappers Summary: This patch is a refinement of the original commit (which was reverted): commit 6b976eb89fe72827f226506d16d3721ba4e28bab Date: Fri Jan 13 08:56:53 2017 +0000 Record evaluated-ness on workers and wrappers In Trac #13027, comment:20, I noticed that wrappers created after demand analysis weren't recording the evaluated-ness of strict constructor arguments. In the ticket that led to a (debatable) Lint error but in general the more we know about evaluated-ness the better we can optimise. This commit adds that info * both in the worker (on args) * and in the wrapper (on CPR result patterns). See Note [Record evaluated-ness in worker/wrapper] in WwLib On the way I defined Id.setCaseBndrEvald, and used it to shorten the code in a few other places Then I added test T13077a to test the CPR aspect of this patch, but I found that Lint failed! Reason: simpleOptExpr was discarding evaluated-ness info on lambda binders because zapFragileIdInfo was discarding an Unfolding of (OtherCon _). But actually that's a robust unfolding; there is no need to discard it. To fix this: * zapFragileIdInfo only zaps fragile unfoldings * Replace isClosedUnfolding with isFragileUnfolding (the latter is just the negation of the former, but the nomenclature is more consistent). Better documentation too Note [Fragile unfoldings] * And Simplify.simplLamBndr can now look at isFragileUnfolding to decide whether to use the longer route of simplUnfolding. For some reason perf/compiler/T9233 improves in compile-time allocation by 10%. Hooray Nofib: essentially no change: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +0.0% -0.3% +0.9% +0.4% +0.0% -------------------------------------------------------------------------------- Min +0.0% -0.3% -2.4% -2.4% +0.0% Max +0.0% +0.0% +9.8% +11.4% +2.4% Geometric Mean +0.0% -0.0% +1.1% +1.0% +0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:32:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:32:34 -0000 Subject: [GHC] #10141: CUSK mysteries (was: Kind inference regression in closed type families) In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.a26a5fbd9f2ec1c96338e2d86dbaf2b4@haskell.org> #10141: CUSK mysteries -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10141 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's an example that I was baffled by. This works {{{ type family F (a :: k) type instance F Maybe = Char }}} But this does not. {{{ type family F (a :: k) where -- = r | r -> a where F Maybe = Char }}} The latter is rejected with {{{ Foo.hs:6:5: error: * Expecting one more argument to `Maybe' Expected kind `k', but `Maybe' has kind `* -> *' * In the first argument of `F', namely `Maybe' In the type family declaration for `F' }}} It is bizarre that one works and the other does not, and I was all ready to open a ticket when Richard said: This is correct behavior. The former has a CUSK, as all open type families have CUSKs with un-annotated kinds defaulting to Type. The latter does not have a CUSK, because the result kind is unknown. You therefore cannot specialize the k variable in the definition of the latter. I can't help feeling that our CUSK story is a bit wonky, so I'm recording it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 17:35:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 17:35:57 -0000 Subject: [GHC] #10141: CUSK mysteries In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.04a0dbece9a711787f451134bcb2031b@haskell.org> #10141: CUSK mysteries -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10141 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 20:02:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 20:02:34 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel In-Reply-To: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> References: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> Message-ID: <060.d417974db2335284be99c213465237e9@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Is that a problem worth investing manpower in, instead of throwing computing power at it? Also, > Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. whether only the most recent version is of interest is something that we may only know later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 20:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 20:26:23 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel In-Reply-To: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> References: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> Message-ID: <060.6e53d6021159ca4f681bf95cdf5b58ba@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Certainly if there were more available OSX and Windows machines it would be fine but it needs someone to provide them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 21:08:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 21:08:11 -0000 Subject: [GHC] #13243: make test in non-validate configuration fails with a variety of ghci errors Message-ID: <046.050e5e1adf77fffffbf4ae5eeb1ad346@haskell.org> #13243: make test in non-validate configuration fails with a variety of ghci errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting with a fresh checkout of `ghc`, testing in a non-validate configuration fails in a rather peculiar way. e.g., {{{ $ ./boot $ ./configure $ make $ make test }}} Results in a number of test failures of the `ghci` way which suggest that GHCi is having trouble identifying types. e.g., {{{ =====> break026(ghci) 50 of 101 [0, 46, 0] cd "./ghci.debugger/scripts/break026.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< break026.script Actual stderr output differs from expected: diff -uw "/dev/null" "./ghci.debugger/scripts/break026.run/break026.run.stderr.normalised" --- /dev/null 2017-01-24 15:20:36.872346204 -0500 +++ ./ghci.debugger/scripts/break026.run/break026.run.stderr.normalised 2017-02-08 15:52:09.290099692 -0500 @@ -0,0 +1,14 @@ + +:16:1: + No instance for (Show t1) arising from a use of ‘print’ + Cannot resolve unknown runtime type ‘t1’ + Use :print or :force to determine these types + Relevant bindings include it :: t1 (bound at :16:1) + These potential instances exist: + instance Show Ordering -- Defined in ‘GHC.Show’ + instance Show Integer -- Defined in ‘GHC.Show’ + instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ + ...plus 22 others + ...plus 11 instances involving out-of-scope types + (use -fprint-potential-instances to see them all) + In a stmt of an interactive GHCi command: print it *** unexpected failure for break026(ghci) =====> break027(ghci) 51 of 101 [0, 47, 0] cd "./ghci.debugger/scripts/break027.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< break027.script Actual stdout output differs from expected: diff -uw "./ghci.debugger/scripts/break027.run/break027.stdout.normalised" "./ghci.debugger/scripts/break027.run/break027.run.stdout.normalised" --- ./ghci.debugger/scripts/break027.run/break027.stdout.normalised 2017-02-08 15:52:10.750125249 -0500 +++ ./ghci.debugger/scripts/break027.run/break027.run.stdout.normalised 2017-02-08 15:52:10.750125249 -0500 @@ -1,8 +1,8 @@ Breakpoint 0 activated at QSort.hs:4:12-13 Breakpoint 1 activated at QSort.hs:5:16-51 Stopped in QSort.qsort, QSort.hs:5:16-51 -_result :: [Integer] = _ -a :: Integer = 3 -left :: [Integer] = _ -right :: [Integer] = _ -a :: Integer -- Defined in ‘interactive:Ghci1’ +_result :: [a] = _ +a :: a = _ +left :: [a] = _ +right :: [a] = _ +a :: a -- Defined in ‘interactive:Ghci1’ *** unexpected failure for break027(ghci) =====> print001(ghci) 11 of 101 [0, 7, 0] cd "./ghci.debugger/scripts/print001.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< print001.script Actual stdout output differs from expected: diff -uw "./ghci.debugger/scripts/print001.run/print001.stdout.normalised" "./ghci.debugger/scripts/print001.run/print001.run.stdout.normalised" --- ./ghci.debugger/scripts/print001.run/print001.stdout.normalised 2017-02-08 15:51:08.413033889 -0500 +++ ./ghci.debugger/scripts/print001.run/print001.run.stdout.normalised 2017-02-08 15:51:08.413033889 -0500 @@ -1,10 +1,9 @@ li = (_t1::[Maybe Integer]) Just 0 -li = Just 0 : (_t2::[Maybe Integer]) +li = (_t2::[Maybe Integer]) 6 -li = [Just 0,(_t3::Maybe Integer),(_t4::Maybe Integer), - (_t5::Maybe Integer),(_t6::Maybe Integer),(_t7::Maybe Integer)] -li = [Just 0,_,_,_,_,_] +li = (_t3::[Maybe Integer]) +li = _ [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] -li = [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] -li = [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] +li = (_t4::[Maybe Integer]) +li = _ *** unexpected failure for print001(ghci) }}} It would be nice to know what is going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 21:42:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 21:42:33 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families Message-ID: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------------+--------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: pprIfaceCo | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hello, I was playing with unboxed types and this happened: [2 of 2] Compiling Data.Unbox ( Data/Unbox.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Data/Unbox.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): pprIfaceCo I will attach the relevant file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 21:42:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 21:42:59 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.7d9217f3cedc4d1efbdfdfe58ce99482@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by sgschlesinger): * Attachment "Unbox.hs" added. The relevant code -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 8 23:47:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Feb 2017 23:47:10 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.2d5428a2a3a736cbe8bbd11811afcd92@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 dsc): Thank you very much! Avoiding the `snd` indeed fixes it in this case, and I'll also keep problem 1 in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 00:02:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 00:02:55 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 Message-ID: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 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: -------------------------------------+------------------------------------- From https://hackage.haskell.org/package/base-4.9.1.0/docs/src/GHC.IO.FD.html {{{ -- We used to use System.Posix.Internals.dEFAULT_BUFFER_SIZE, which is -- taken from the value of BUFSIZ on the current platform. This value -- varies too much though: it is 512 on Windows, 1024 on OS X and 8192 -- on Linux. So let's just use a decent size on every platform: dEFAULT_FD_BUFFER_SIZE :: Int dEFAULT_FD_BUFFER_SIZE = 8096 }}} 8096 is not a power of two, and does not agree with the original commit message that sets it to 8KB (https://github.com/ghc/ghc/blame/master/libraries/base/GHC/IO/FD.hs#L119). Confirmed by Simon Marlow on IRC that this is a typo, a mix between 8192 and 4096. I'll send a patch to set it to 8192. It would be nice if the fix could be released in both GHC 8.2 and and 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 00:03:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 00:03:40 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes Message-ID: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13245 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To get good performance, it is better to use few system calls that write lots of data in batch. I found a bug in hPutBuf that makes this concept not work: When using `hPutBuf` with a buffer size greater than 8095 (this number it self is a bug, #13245) bytes, two syscalls are issued instead of one: one empty `write("")` (a zero-bytes-write, which can't do anything useful), and after that the actual useful `write()` of the data. Example code: {{{ main = do withBinaryFile "testfile2" WriteMode $ \ hTo -> do let bufferSize = 8096 allocaBytes bufferSize $ \buffer -> do Main.hPutBuf hTo buffer bufferSize }}} In `strace -f -T` on the compiled binary, we see the syscalls: {{{ write(3, "", 0) = 0 <0.000004> write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8096) = 8096 <0.000017> }}} As you can see in the timings, this also has a fairly large performance overhead (20% in this case). When using `bufferSize = 8095`, the `write("")` disappears. The problem is this code for `bufWrite` (called by `hPutBuf`): {{{ bufWrite :: Handle__-> Ptr Word8 -> Int -> Bool -> IO Int bufWrite h_ at Handle__{..} ptr count can_block = seq count $ do -- strictness hack old_buf at Buffer{ bufRaw=old_raw, bufR=w, bufSize=size } <- readIORef haByteBuffer -- enough room in handle buffer? hPutStrLn System.IO.stderr (show (size, w, count)) if (size - w > count) -- There's enough room in the buffer: -- just copy the data in and update bufR. then do debugIO ("hPutBuf: copying to buffer, w=" ++ show w) copyToRawBuffer old_raw w ptr count writeIORef haByteBuffer old_buf{ bufR = w + count } return count -- else, we have to flush else do debugIO "hPutBuf: flushing first" old_buf' <- Buffered.flushWriteBuffer haDevice old_buf -- TODO: we should do a non-blocking flush here writeIORef haByteBuffer old_buf' -- if we can fit in the buffer, then just loop if count < size then bufWrite h_ ptr count can_block else if can_block then do writeChunk h_ (castPtr ptr) count return count else writeChunkNonBlocking h_ (castPtr ptr) count }}} The check `if (size - w > count)` should be `if (size - w >= count)` instead, because we can do the write all fine if it fits exactly. In the adversarial case, `size - w == count`, we go into the `hPutBuf: flushing first` branch, thus emitting the `write("")`. See https://github.com/ghc/ghc/blame/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/libraries/base/GHC/IO/Handle/Text.hs#L740 for the full code. Simon Marlow has confirmed this on IRC, I'll submit a patch for it that switches to `>=`. It would be nice if the fix could be released in both GHC 8.2 and and 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 00:14:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 00:14:56 -0000 Subject: [GHC] #13247: hPutBufNonBlocking can block Message-ID: <042.d8cc62e67aa7b3a461991ea20822ead1@haskell.org> #13247: hPutBufNonBlocking can block -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13246, #13245 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This simply escalates an existing TODO in the code base to a ticket. The function `System.IO.hPutBufNonBlocking` [1] calls `hPutBuf'` with `can_block = False`, which is commented as `Bool -- allow blocking?` ([https://github.com/ghc/ghc/blame/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/libraries/base/GHC/IO/Handle/Text.hs#L708-L713 relevant lines]) However, `hPutBuf'` calls `bufWrite`, inside which there's the comment ([https://github.com/ghc/ghc/blame/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/libraries/base/GHC/IO/Handle/Text.hs#L751 relevant line]): {{{ if (...) -- There's enough room in the buffer: -- just copy the data in and update bufR. then do ... -- else, we have to flush else do ... old_buf' <- Buffered.flushWriteBuffer haDevice old_buf -- TODO: we should do a non-blocking flush here }}} so it turns out that if there's not enough room in the `Handle` buffer, then `hPutBufNonBlocking` will block. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 00:24:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 00:24:45 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.ea26893f0a5ed369d098071c992039de@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I've extracted the relevant code into a simple-to-run-and-modify single file, so that we can play around with it without recompiling `base`: * [https://gist.github.com/nh2/4cd40c2a4b15bf056bcae87907773786#file-ghc- bug-13246-repro-hs Without fix] * [https://gist.github.com/nh2/4cd40c2a4b15bf056bcae87907773786#file-ghc- bug-13246-fix-hs With fix] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 00:41:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 00:41:45 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.2ec2228693055ad1cdef9730915c57e5@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bitonic): * cc: bitonic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 00:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 00:52:22 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel In-Reply-To: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> References: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> Message-ID: <060.76c5c18831a21661db34cc51cf8e0345@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 nomeata]: > Is that a problem worth investing manpower in, instead of throwing computing power at it? > > Also, > > > Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. > > whether only the most recent version is of interest is something that we may only know later. Yes, we would prefer to throw more computing power in, but we don't have it. And yes, it's true that there can be surprisingly interesting features in just about any build. If we had sufficient build resources, we would certainly want to run them all so we could catch those gems. But in reality our build resources are extremely limited; we have to decide between letting things pile up over the course of the day, hoping that they'll be cleared up overnight, and losing some potentially useful information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 01:01:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 01:01:01 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.56040196096d30e41bbb27cc244eb7f7@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 ezyang): I don't think it's good to read too much into what Haskell'98 says should be the set of visible instances; after all, Haskell'98 doesn't formalize overloaded syntax. There are a few possible ways to adjust the semantics, but one possibility is to say that if the renamer inserts a reference directly to something (that wasn't imported), that implicitly imports the module that provided that original name. This might be annoying to implement, but anything along these lines should be OK? (Certainly, it's what I would expect!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 02:21:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 02:21:49 -0000 Subject: [GHC] #10141: CUSK mysteries In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.60bb801663ae765451ba412ee66fa1c9@haskell.org> #10141: CUSK mysteries -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10141 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If you want `TypeInType` to mean "Richard's bailiwick", that's perhaps convenient. But I'll note that this problem has nothing to do with `-XTypeInType` and exists in 7.10 and perhaps 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 02:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 02:24:20 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.ccdb8b6c525c6928e8f238096d940b75@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed with comment:37. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 03:29:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 03:29:34 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.08d86498a532ee1386d4929dfbf9d9ed@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, 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): As comment:63 says, this patch (available on the `wip/t11715` branch) is in limbo. What's the challenge? See [https://phabricator.haskell.org/D2038#inline-25457 this comment] on a related patch. The short version is that the design in comment:47 and in the [https://github.com/ghc-proposals/ghc-proposals/pull/32 ghc-proposal] require weakening `KindCo` to work only on nominal coercions. And Phab:D2038 requires it to work on representational ones. The decision was to punt on this patch in favor of that one. There is a somewhat-detailed plan of how to proceed, originally posted [https://mail.haskell.org/pipermail/ghc-devs/2017-February/013702.html here]: 1. Hold off on Constraint v Type until after the branch is cut. 2. Do what we can to mitigate Constraint v Type confusion vis-a-vis Typeable. (For example, make sure that there aren't Typeable instances for both, and have TcTypeable provide the Type instance whenever the Constraint instance is requested.) 3. Advertise that GHC will be a little confused on this point, and that, as far as Typeable is concerned, Constraint and Type are synonymous. 4. On the Constraint v Type patch, restore the full power of KindCo. This makes the type system broken, but I don't think the sky will come crashing down. 5. Merge Constraint v Type after the branch is cut. This will make GHC HEAD unsound in a new way, but no one will notice unless they try. 6. File a priority-highest bug to eliminate newtype-classes (which beget heterogeneous axioms in the Constraint/=Type world). 7. Finish the first-class reification design and implement before 8.4. 8. Remove newtype-classes, thus eliminating heterogeneous axioms and the unsoundness mentioned in (5). This plan was met with general applause. But a recent chat with Simon suggested a new direction, that would allow us to separate Constraint from Type while keeping the efficiency of newtype-classes. In brief: * Allow representational casts in kinds, resurrecting sections 5 and 6 of an [http://cs.brynmawr.edu/~rae/papers/2015/equalities/equalities.pdf unpublished paper of mine]. Currently, all kind-casts (that is, all uses of `CastTy` to change the kind of a type) use nominal coercions. This means that if we separate Constraint from Type, any equating of `C a` with `a` (in `class C a where meth :: a`) will somehow lead to a nominal equality between Constraint and Type, precisely the situation we wish to avoid. But if we allow representational coercions in kinds, then we can arrange to have `Constraint ~R Type` but not `Constraint ~N Type`. Indeed this makes more intuitive sense, because `Constraint` and `Type` do have the same runtime representation, but we wish to keep them separate regardless. Sadly, representational coercions in kinds are troublesome, as described [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#RolesCoherenceandKinds here] and in that unpublished paper. The paper details a kind system that circumvents the problem, and thus presents a plausible way forward. But it requires yet more wrinkles in GHC's coercion language. Is this worth it? Perhaps. Previously, Simon vetoed that system as overly complicated. The nub of his argument was that there was no point in having roles in kind- coercions. But now, we have a reason to do this, so it might be well- advised to revisit that decision. It's also possible that any wisdom I have accumulated in the intervening years may come to bear and help us out. Another approach that we considered was to have three different, unrelated arrow types: `(->) :: TYPE r1 -> TYPE r2 -> Type`, `(=>) :: Constraint -> TYPE r -> Type`, `(=>) :: Constraint -> Constraint -> Type`, where the last one is used to build dictionaries. Having these arrows like this prevents the need for `KindCo` to work on representational coercions -- thus removing the incompatibility between the original solution proposed in comment:47 and the work in Phab:D2038. This would work, and would allow us to keep `C a ~R a`, but then we couldn't have `(C a => a) ~R (a -> a)`, so the newtype-class efficiency would run out of gas fairly quickly. I do think, in the long run, that having representational coercions in kinds is the Right Answer, because it will be necessary to support promoting newtypes to kinds, necessary for full [http://cs.brynmawr.edu/~rae/papers/2016/thesis/eisenberg-thesis.pdf dependent types]. I don't expect any action on this until the summer, at least, but I wanted to jot it all down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 04:28:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 04:28:26 -0000 Subject: [GHC] #13248: Allow an injective type family RHS to be another injective type family Message-ID: <044.7f820fc78fab115fd03f04c386b38536@haskell.org> #13248: Allow an injective type family RHS to be another injective type family -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Example use case: {{{#!hs {-# LANGUAGE TypeFamilies, TypeFamilyDependencies, UndecidableInstances #-} type family Foo a = r | r -> a where Foo Int = Char Foo Integer = String type family Bar a = r | r -> a where Bar Char = Double Bar String = Float type family Baz a = r | r -> a where Baz x = Bar (Foo x) }}} 8.0 says: {{{ test.hs:12:9: error: • Type family equation violates injectivity annotation. RHS of injective type family equation cannot be a type family: Baz x = Bar (Foo x) -- Defined at test.hs:12:9 • In the equations for closed type family ‘Baz’ In the type family declaration for ‘Baz’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 06:05:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 06:05:06 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous Message-ID: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: #12918 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `bytes` library currently doesn't compile with GHC `master` due to the new check of default signatures (7363d5380e600e2ef868a069d5df6857d9e5c17e, #12918). Consider this example, {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DefaultSignatures #-} module Hi where import Control.Monad.Trans.Class class MonadGet m where type Remaining m :: * remaining :: m (Remaining m) default remaining :: (MonadTrans t, MonadGet n, m ~ t n) => m (Remaining (t m)) remaining = lift remaining }}} Patching this up requires a fair amount of hand-holding, {{{#!hs default remaining :: (MonadTrans t, MonadGet n, m ~ t n, Remaining m ~ Remaining n, Monad n) => m (Remaining m) }}} Yuck. I suppose this is just how the world works, but I thought I'd leave this here in case anyone had a clever idea for improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 06:06:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 06:06:46 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous In-Reply-To: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> References: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> Message-ID: <061.ea2c4ae38036d5062a9ce75bb4f271c3@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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: #12918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -15,1 +15,1 @@ - (t m)) + (t n)) New description: The `bytes` library currently doesn't compile with GHC `master` due to the new check of default signatures (7363d5380e600e2ef868a069d5df6857d9e5c17e, #12918). Consider this example, {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DefaultSignatures #-} module Hi where import Control.Monad.Trans.Class class MonadGet m where type Remaining m :: * remaining :: m (Remaining m) default remaining :: (MonadTrans t, MonadGet n, m ~ t n) => m (Remaining (t n)) remaining = lift remaining }}} Patching this up requires a fair amount of hand-holding, {{{#!hs default remaining :: (MonadTrans t, MonadGet n, m ~ t n, Remaining m ~ Remaining n, Monad n) => m (Remaining m) }}} Yuck. I suppose this is just how the world works, but I thought I'd leave this here in case anyone had a clever idea for improvement. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 07:45:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 07:45:25 -0000 Subject: [GHC] #13250: Backpack: matching newtype selectors doesn't work Message-ID: <045.0e7a960652fd03d6405838b3d76bce63@haskell.org> #13250: Backpack: matching newtype selectors doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ unit p where signature A where newtype F a = F { mkF :: a } unit q where module A where newtype F a = F { mkF :: a } unit r where dependency p[A=q:A] }}} fails with {{{ ezyang at sabre:~$ ghc-head --backpack selector.bkp -dppr-debug [1 of 3] Processing p [2 of 3] Processing q Instantiating q [1 of 1] Compiling A ( q/A.hs, q/A.o ) [3 of 3] Processing r Instantiating r [1 of 1] Including p[A=q:A] Instantiating p[A=q:A] [1 of 1] Compiling A[sig] ( p/A.hsig, p/p-HVmFlcYSefiK5n1aDP1v7x/A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170123 for x86_64-unknown-linux): TcIface.find_lbl missing: mkF{v} known labels: [mkF{q:A.mkF{v rb}}] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:841:41 in ghc:TcIface }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 09:09:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 09:09:58 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.891fa268c391c979f2b0a9ed3572121d@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): What about looking at compiler allocations for nofib, to try to get a smaller example? I think this should be an 8.2 release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 09:35:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 09:35:50 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.3824ed9b43119014160f3fdd8d6ba1b3@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:04:08 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.a5e724e804db00337405a4b2baeabac7@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by simonpj): Can you explain how to provoke the error? I tried {{{ ghc -c T13244.hs }}} and all was well. (But I may not have used exactly the version that you did..) Probably a dup of #12242 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:30:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:30:40 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers Message-ID: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies | 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: -------------------------------------+------------------------------------- Currently, the family consistency check checks pairs of *imported* modules (and the modules they transitively import) for consistency. However, there are a number of mechanisms by which we can refer to an identifier from a module without explicitly importing it. Here is one example from Template Haskell: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Bool = String g :: F Bool g = "af" -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import A type instance F Bool = Int h :: F Bool -> IO () h = print -- D.hs {-# LANGUAGE TemplateHaskell #-} import C import Language.Haskell.TH.Syntax main = h $( return (VarE (Name (OccName "g") (NameG VarName (PkgName "main") (ModName "B")))) ) }}} This does an unsafe coerce: {{{ ezyang at sabre:~/Dev/labs/T13102$ ghc-head --make B.hs D.hs -fforce-recomp [1 of 4] Compiling A ( A.hs, A.o ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling C ( C.hs, C.o ) [4 of 4] Compiling Main ( D.hs, D.o ) Linking D ... ezyang at sabre:~/Dev/labs/T13102$ ./D 8070450533355229282 }}} Clearly, checking consistency on imports is not enough: we must also check up on original names that come by other mechanisms. (Other ways we can end up with identifiers without imports include overloading, see #13102. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:44:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:44:39 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.629b9a1e1093c99bb15b8f3a7cf34c48@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -54,0 +54,25 @@ + + A few things to note about how to fix this: + + * Currently, type family instances are checked for consistency as we + process imports. Template Haskell splices can occur much later in a + Haskell file, so we must correspondingly do these checks later. + + * If we refer to an identifier by synthesizing a name manually, it is as + if we imported it. This also means that a reference of this sort implies + an implicit import of the defining module (#13102) and we should consider + instances from it visible (at the moment, it's not considered visible.) + (Actually, with TH, this is a bit tricky, because if we take these + semantics, an instance might be visible below a top-level splice, but + invisible above it.) + + * It is probably simplest if the type family compatibility check happens + at the end. So we should go ahead and revive idea (2) from + https://ghc.haskell.org/trac/ghc/ticket/11062#comment:9 ; if there are + overlapping families we should just not reduce the type family. + + * For wired in things, it's pretty easy to find out if we have an implicit + import: if we bang on `checkWiredInTyCon`, that means we intended for the + instance to visible; so we should collect all of the TyCons we banged on + this way. For TH, this isn't exactly going to work, but maybe we can just + track when NameGs get synthesized. New description: Currently, the family consistency check checks pairs of *imported* modules (and the modules they transitively import) for consistency. However, there are a number of mechanisms by which we can refer to an identifier from a module without explicitly importing it. Here is one example from Template Haskell: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Bool = String g :: F Bool g = "af" -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import A type instance F Bool = Int h :: F Bool -> IO () h = print -- D.hs {-# LANGUAGE TemplateHaskell #-} import C import Language.Haskell.TH.Syntax main = h $( return (VarE (Name (OccName "g") (NameG VarName (PkgName "main") (ModName "B")))) ) }}} This does an unsafe coerce: {{{ ezyang at sabre:~/Dev/labs/T13102$ ghc-head --make B.hs D.hs -fforce-recomp [1 of 4] Compiling A ( A.hs, A.o ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling C ( C.hs, C.o ) [4 of 4] Compiling Main ( D.hs, D.o ) Linking D ... ezyang at sabre:~/Dev/labs/T13102$ ./D 8070450533355229282 }}} Clearly, checking consistency on imports is not enough: we must also check up on original names that come by other mechanisms. (Other ways we can end up with identifiers without imports include overloading, see #13102. A few things to note about how to fix this: * Currently, type family instances are checked for consistency as we process imports. Template Haskell splices can occur much later in a Haskell file, so we must correspondingly do these checks later. * If we refer to an identifier by synthesizing a name manually, it is as if we imported it. This also means that a reference of this sort implies an implicit import of the defining module (#13102) and we should consider instances from it visible (at the moment, it's not considered visible.) (Actually, with TH, this is a bit tricky, because if we take these semantics, an instance might be visible below a top-level splice, but invisible above it.) * It is probably simplest if the type family compatibility check happens at the end. So we should go ahead and revive idea (2) from https://ghc.haskell.org/trac/ghc/ticket/11062#comment:9 ; if there are overlapping families we should just not reduce the type family. * For wired in things, it's pretty easy to find out if we have an implicit import: if we bang on `checkWiredInTyCon`, that means we intended for the instance to visible; so we should collect all of the TyCons we banged on this way. For TH, this isn't exactly going to work, but maybe we can just track when NameGs get synthesized. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:47:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:47:59 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.52adc8ac055aef2335440d8de957a398@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 ezyang): simonpj and I chatted about this, and we came up with a short term and a long term solution. * The short term solution is to special-case GHC.Exts so that it is always visible. This should be pretty easy to do. * But, if we look at how the compiler handles finding instances of wired in things, there is a `checkWiredInTyCon` function which we specifically call in order to bring in the instances for a wired in thing. So really, the desired semantics are, if we call `checkWiredInTyCon` on a `TyCon`, we want to act AS IF we had an implicit import of this `TyCon`. This means checking it for family instance consistency (see #13251) and considering it visible. But now that I think about it, it seems very awkward to actually get this info to the list of visible info, since we won't really bang on the TyCon until we're about to do an instance lookup; might be a little fiddly to get that to work. But the long term solution is something like this: an implicit reference to a wired in thing counts as an import to that defining module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:48:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:48:20 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic (type family consistency check too early) In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.bceaf1dcc8f6eab77b15aa40ffb341b1@haskell.org> #11062: Type families + hs-boot files = panic (type family consistency check too early) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: TypeFamilies | hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2859 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): See #13251 for a follow-up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:48:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:48:34 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous In-Reply-To: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> References: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> Message-ID: <061.2a797d567df41e52b036f6b13ef214bc@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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: #12918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well it's true, isn't it? We are simply listing the conditions under which you can use the generic default instance. The more constraints you need, the less generally-applicable it is. In this case you are saying that you can say {{{ instance MonadGet ty where type Remaining ty = blah -- no code for 'remaining' }}} only if: * `ty` is of form `(t n)` * We have `MonadTrans t, MonadGet n, Monad n` * `Remaining (t n)` equals `Remaining n`. Fair enough -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:52:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:52:58 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.8c4b0157bfe5e3034bdc88840c2af1f7@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by sgschlesinger): * Attachment "lint-errors.txt" added. lint errors from "stack build --ghc-options -dcore-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:53:42 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.ce12523593c67e513edbd7bf2c090ff1@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by sgschlesinger): I'm using stack with resolver lts-7.19 which uses ghc 8.0.1. I ran stack build --ghc-options -dcore-lint and got quite the atrocious output which I will attach to the issue. The error I got originally was from a dup of #12242 almost certainly, but could the -dcore-lint errors have been caused by that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:57:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:57:06 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.4bc941727494f501274c113e3c224f19@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by simonpj): Could you provoke it with an invocation of GHC, not via stack? One less indirection. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 10:57:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 10:57:43 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.f9e8b098c6b4788f2d493eb979358bda@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * version: 7.8.3 => 8.0.1 Comment: Unfortunately, I was able to reproduce with GHC 8.0.1, so I guess the visibility changes were not enough. Could it be that `~` instances are treated specially? Investigation necessary! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 11:01:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 11:01:28 -0000 Subject: [GHC] #13252: Perf: Make dep_finsts a map from type family Name to Module Message-ID: <045.b72311e30e9fb5fc5e3bed039056d14b@haskell.org> #13252: Perf: Make dep_finsts a map from type family Name to Module -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | 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: -------------------------------------+------------------------------------- Today, when we do a family consistency check, we always do a pairwise comparison of every module, even though most of the time, the modules don't even define instances of the same family (making the check futile.) A far better strategy is to say, for any family, which modules transitively below us define instances for it, and only check THOSE pairwise. All we have to do is turn dep_finsts from a list of modules into a mapping from type family names to modules; then we can union the maps and do pairwise comparisons as before. Note that we want to RECORD the map from Name to Module, because we expect any family to have instances defined in many modules (Module to Name is better if a single module defines instances for many families, but clearly this is rare.) This is related to #9717, in that the proposed map here is a more coarse version of what was proposed in that ticket. This may strike a happy compromise between keeping interface files small and speeding things up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 11:02:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 11:02:47 -0000 Subject: [GHC] #13248: Allow an injective type family RHS to be another injective type family In-Reply-To: <044.7f820fc78fab115fd03f04c386b38536@haskell.org> References: <044.7f820fc78fab115fd03f04c386b38536@haskell.org> Message-ID: <059.f40ceb34bfdde61d2c88b403155f23e3@haskell.org> #13248: Allow an injective type family RHS to be another injective type family -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If I recall correctly this is by design. It's explained in [https://www.microsoft.com/en-us/research/publication/injective-type- families-haskell/ Section 4.1 of the paper]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 11:34:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 11:34:36 -0000 Subject: [GHC] #13158: Pattern synonyms should use type annotation information when typechecking In-Reply-To: <050.659214f5530244fc33d6e67036d296e2@haskell.org> References: <050.659214f5530244fc33d6e67036d296e2@haskell.org> Message-ID: <065.76c39ebbfa98da3dd5c5e22ba3519ca3@haskell.org> #13158: Pattern synonyms should use type annotation information when typechecking -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13159, #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: This is a tricky one, but I think it is behaving correctly. Imagine desugaring it `evilId` like this {{{ -- The original -- evilId (EqT (n :: Int)) = n + 1 -- Desugars to evilId :: Typeable a => a -> a evilId x = case viewEqT x of Just (Refl, (n :: Int)) -> n + 1 Nothing -> error "urk" }}} (The `error "urk"` is just a stub; in reality we arrange to fall through to the next equation, but we can ignore that here.) This fails with {{{ T13158.hs:31:27: error: • Could not deduce: a ~ Int from the context: b0 ~ a bound by a pattern with constructor: Refl :: forall k (a :: k). a :~: a, in a case alternative at T13158.hs:31:20-23 }}} It's not a great error message, but the payload is this * When calling `viewEqT` we must choose what types to instantiate it at; say `b := beta` and `a := alpha`. * Now the `Refl` brings into scope `alpha ~ beta`. * Now, inside that `Refl` match, the type signature `(n :: Int)` tells us that we need `beta ~ Int`. But `beta` is untouchable here (because of the equality) so we can't unify it. That is why you needed the type application in your other version `viewEqT @Int -> Just (Refl, n)` As #13159 points out, if we had type applications in patterns we could write {{{ evilId (EqT @Int n) = ... }}} The ticket for that is #11350. Meanwhile I'll close this one as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 11:35:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 11:35:01 -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.c0b0ba6b9546c1e77e530ab421ae6d53@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: #11385, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #11385, #13159 => #11385, #13159, #13158 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 12:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 12:59:12 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` Message-ID: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- See the attached file. The compilation time grows exponentially with additional fields in `HuteStruct`. Tried with GHC-8.0.1 and quite recent HEAD (8.2) adding a field doubles the compilation time with `-O2`. - 9: 17s - 10: 34s - 11: 83s on my machine. With `-01` around 3sec, independently of the struct size. The original issue: https://github.com/yesodweb/yesod/issues/1348 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 13:01:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 13:01:56 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.0c2f6f953986618b57808818a8acb5d1@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by phadej): * Attachment "bad.hs" added. Example file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 13:14:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 13:14:28 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.af4acf8846f8c5f6bbcbf92bb7d19a2a@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): We suspect the problem is that `<*>` for `RWST` is marked as `INLINE` in transformers. This ticket is to check whether that is the case and then decide on the course of action. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 13:25:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 13:25:11 -0000 Subject: [GHC] #13254: Confusing error message from GHCI - "defined in multiple files" shows the same file Message-ID: <047.9e2b0788034c8e8a454fc38ecb47d607@haskell.org> #13254: Confusing error message from GHCI - "defined in multiple files" shows the same file -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 just had the following very confusing exchange with GHCI: {{{ λ :load Ok, modules loaded: none. λ :load src/Application/Aws.hs Ok, modules loaded: Application.Aws (dist/build/Application/Aws.o). λ private :3:1: error: Variable not in scope: private λ :m *Application.Aws module 'Application.Aws' is not interpreted; try ':add *Application.Aws' first λ :add *Application.Aws : error: module ‘circuithub-api-0.0.4-EeGo4QUTODrB58BZrr3htj:Application.Aws’ is defined in multiple files: src/Application/Aws.hs src/Application/Aws.hs Failed, modules loaded: Application.Aws (dist/build/Application/Aws.o). λ :! ghc --version The Glorious Glasgow Haskell Compilation System, version 8.1.20161115 }}} This can really be simplified to {{{ λ :load src/Application/Aws.hs Ok, modules loaded: Application.Aws (dist/build/Application/Aws.o). λ :add *Application.Aws : error: module ‘circuithub-api-0.0.4-EeGo4QUTODrB58BZrr3htj:Application.Aws’ is defined in multiple files: src/Application/Aws.hs src/Application/Aws.hs Failed, modules loaded: Application.Aws (dist/build/Application/Aws.o). }}} For the record, here is Application.Aws: {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} module Application.Aws ( AwsExtra(..) ) where import Prelude import Data.Data (Data) import Data.ByteString.Char8 import Data.Text data AwsExtra = AwsExtra { awsKey :: ByteString , awsSecret :: ByteString , awsS3AssetsBucket :: Text } deriving (Show,Data) private :: Int private = 42 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 13:28:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 13:28:06 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.c310625905e7647b9fcc5b987bafd6fe@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): This would be a very welcome change! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 13:31:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 13:31:50 -0000 Subject: [GHC] #13254: Confusing error message from GHCI - "defined in multiple files" shows the same file In-Reply-To: <047.9e2b0788034c8e8a454fc38ecb47d607@haskell.org> References: <047.9e2b0788034c8e8a454fc38ecb47d607@haskell.org> Message-ID: <062.f924be489c74fb95dc6738abef9cab50@haskell.org> #13254: Confusing error message from GHCI - "defined in multiple files" shows the same file -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 ocharles): This only happens with `-fobject-code`. If that's not on, then it does indeed load the interpreted version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 13:34:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 13:34:06 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.3458384fcc158d5ae49aebf3d00cebe9@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): One question about the implementation: Do we have to be careful with recompilation avoidance / reproducible builds / interface hashes here? E.g. if the `String` passed to `addModCStub` is different between two builds, should that invalidate any modules further down? Or could, through recursive tracing of `include`s, the behaviour of a module change when the module is loaded from TemplateHaskell, so that e.g. the entire preprocessor-expanded C code should make its way into an interface hash? (Note I haven't actually analysed if it's possible for the generated C code to be used in TemplateHaskell later in the same compilation pass, just some ideas that went through my head.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 15:01:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 15:01:24 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.8f4f272c46f48b480a7484e15d6b8a94@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I'd say that if the string changes, programs and libraries would need to be relinked. But I don't see now why a downstream module would need to be rebuilt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 15:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 15:56:52 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.18ee2895142367950a3f75c0332f3e7e@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Exponential is bad. Why would marking it INLINE make things go exponential? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 15:59:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 15:59:37 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.55684e0d7143aea16eec3ff39368ac7c@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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'm a bit unclear on both parts of the plan. * You write "special-case GHC.Exts so that it is always visible". Is this a code change? Are we keeping definition 2 for visibility of class instances for now? We don't really have to do anything about GHC.Exts for now, because: 1. For class instance lookup, the `IsList` instances are already treated as visible because they are non-orphan. 2. For type family instance lookup, the plan is to apply the same non- orphan rule as for class instance lookup, so the `Item` instances will be treated as visible too. 3. For type family consistency checking, we need to make sure that a. All family instances that are made visible in this way are consistent with other visible instances. But there's no actual problem here, because in order to ''define'' an instance of `IsList` you still need to import `GHC.Exts`, and then `GHC.Exts` will be in the set of transitively imported family instance modules that gets checked for consistency. (The way there could have been a problem here is if the instances in question were non-orphan because they defined an instance that mentions a type defined in the module, of a type family that is defined in another module.) b. Since the desugarer is going to insert a call to `GHC.Exts.fromListN` into our module `M`, we also need to make sure that the definition of `fromListN` doesn't depend on some other type family instances that were visible in `GHC.Exts`, which might conflict with ones that are visible in our module `M`. But `fromListN` is just a class method, so surely there's no problem there either. In short, `GHC.Exts` is special-cased in the correctness proof, not in the compiler. But there could be other situations in which the arguments of 3a and 3b don't apply, so a better long-term plan is in order. And #13251 already gives an example. * "But, if we look at how the compiler handles finding instances of wired in things"... This sounds reasonable, but the problem here is not just about wired-in things. `IsList` is known-key, not wired-in; and the example using TH in #13251 is neither. In any case, since #13251 is its own ticket, I'll continue here with the short-term plan of using the same rules for type family instance visibility as for class instance visibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 16:01:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 16:01:10 -0000 Subject: [GHC] #13255: aws package fails to build with master Message-ID: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `aws` package from Hackage fails to build with `master`, {{{ [22 of 76] Compiling Aws.DynamoDb.Core ( Aws/DynamoDb/Core.hs, /home/ben/code/mediawiki-annotate/dist- newstyle/build/x86_64-linux/ghc-8.1.20170209/aws-0.14.1/build/Aws/DynamoDb/Core.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170209 for x86_64-unknown-linux): completeCall $wloop_length_s18Cv Stop[BoringCtxt] Int# -> Int# -> Int Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1188:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1192:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1598:9 in ghc:Simplify 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 Feb 9 16:04:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 16:04:41 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous In-Reply-To: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> References: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> Message-ID: <061.289f2cef884c2081f7ae5663a7267c23@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Yes, it is true; I was fearing this would pop up in more Hackage packages after running into it very early in my testing. However, so far `bytes` has been the only package where the constraints blew up to this extent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 16:16:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 16:16:25 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.ec54b3b2a69d0470ca48c158365a1f6c@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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): Not thoroughly thought out, but how about in `checkWiredInTyCon` (or something which wraps it) and in `tcLookupGlobal`, we check whether the thing lives in a module that was actually imported and, if not, add the relevant import information to `tcg_imports`, and either do the ensuing type family consistency checks immediately, or perhaps add them to `tcg_pending_fam_checks`? I mean, we also have this behavior: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH.Syntax main = print $( return (VarE (Name (OccName "sigFPE") (NameG VarName (PkgName "unix-2.7.0.1") (ModName "System.Posix.Signals")))) ) }}} {{{ rwbarton at morphism:~/ghc2$ ghc x/TH -fforce-recomp [1 of 1] Compiling Main ( x/TH.hs, x/TH.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Linking x/TH ... x/TH.o:(.text+0x4b): undefined reference to `unixzm2zi7zi0zi1_SystemziPosixziSignals_sigFPE_closure' x/TH.o: In function `S4hM_srt': (.data+0x48): undefined reference to `unixzm2zi7zi0zi1_SystemziPosixziSignals_sigFPE_closure' collect2: error: ld returned 1 exit status }}} If we updated the `ImportAvails` when we type checked the spliced thing, wouldn't that also create a dependency on the `unix` package at link time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 16:38:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 16:38:12 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.2493b845039a561c9dd20d799479ec39@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): What I had in mind is the following: You have a module that exposes some function `f` that is implemented in C. You have another module that contains a TH function `t` that that calls `f` at compile time. And a third module that uses `$(t)` to generate some code. Then the third module has to be recompiled when the C code or its includes change. Of course this question depends on whether the scenario above is even already possible. To my knowledge with `inline-c` it is not currently possible, but I might be wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 16:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 16:46:15 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.ef353f9cae4ceeb9e1d42ce8f526684d@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 16:54:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 16:54:49 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.79538ddc4f82b41441a996df4d34bbc6@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Looks like the same as #10421. Unfortunately I didn't upload the modules `Form` and `Y` used in the reproducer there, and I can't find copies of them on my system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 17:00:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 17:00:23 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.ecda46655a7d3ba442f4421870bc8afa@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: see ticket Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Comment (by rwbarton): Hi TobyGoodwin, do you still have the reproducer for this issue? I referenced it in #10421, not expecting it to disappear... should have reuploaded it myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 17:05:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 17:05:48 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.e57e0c03763f076431e7d96cb62a4f26@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Even if that scenario is not possible already, it will be possible with this change, so it should be addressed. Anyways, I think it's an equivalent scenario to one in which the implementation of an ordinary function has changed, but in a way that doesn't affect any information that appears in the interface file (e.g. its type or unfolding); and then that function is used in a TH splice in another module. I assume that one of the interface file hashes takes this into account, so it should also take the `addModCStub` calls into account. (Or possibly we don't handle this scenario correctly at present.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 17:14:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 17:14:05 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.c4796d29b5f7e24f508846c50edca005@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): How do I reproduce this? I get {{{ cabal install --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc- stage2 Resolving dependencies... cabal: Could not resolve dependencies: trying: base-4.10.0.0/installed-4.1... (dependency of aws-0.15) next goal: vector (dependency of aws-0.15) rejecting: vector-0.12.0.0 (conflict: base==4.10.0.0/installed-4.1..., vector => base>=4.5 && <4.10) rejecting: vector-0.11.0.0 (conflict: base==4.10.0.0/installed-4.1..., vector => base>=4.3 && <4.10) trying: vector-0.10.12.3 next goal: primitive (dependency of vector-0.10.12.3) rejecting: primitive-0.6.2.0 (conflict: vector => primitive>=0.5.0.1 && <0.6.2) rejecting: primitive-0.6.1.0 (conflict: base==4.10.0.0/installed-4.1..., primitive => base>=4.3 && <4.10) rejecting: primitive-0.5.4.0 (conflict: base==4.10.0.0/installed-4.1..., primitive => base>=4.3 && <4.9) rejecting: primitive-0.5.3.0, primitive-0.5.2.1 (conflict: base==4.10.0.0/installed-4.1..., primitive => base>=4.3 && <4.8) rejecting: primitive-0.5.1.0 (conflict: base==4.10.0.0/installed-4.1..., primitive => base>=4 && <4.8) rejecting: primitive-0.5.0.1 (conflict: base==4.10.0.0/installed-4.1..., primitive => base>=4 && <4.7) rejecting: primitive-0.5, primitive-0.4.1, primitive-0.4.0.1, primitive-0.4, primitive-0.3.1, primitive-0.3, primitive-0.2.1, primitive-0.2, primitive-0.1 (conflict: vector => primitive>=0.5.0.1 && <0.6.2) rejecting: primitive-0.6 (conflict: base==4.10.0.0/installed-4.1..., primitive => base>=4.3 && <4.9) Dependency tree exhaustively searched. simonpj at cam-05-unx:~/tmp/aws-0.15$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 17:59:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 17:59:45 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.293e368495e5d5f1357d6a6abc911e47@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): But note that #10421 doesn't appear to involve transformers; the only monad involved is `IO`. (Though I don't have the definitions of `mreq`, `mopt` or `FormResult`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 18:05:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 18:05:37 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.4f1523b9cdf659d079d4fe41fbcb5a45@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Description changed by rwbarton: @@ -53,1 +53,2 @@ - up with identifiers without imports include overloading, see #13102. + up with identifiers without imports include overloading, see + ticket:13102#comment:13. New description: Currently, the family consistency check checks pairs of *imported* modules (and the modules they transitively import) for consistency. However, there are a number of mechanisms by which we can refer to an identifier from a module without explicitly importing it. Here is one example from Template Haskell: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Bool = String g :: F Bool g = "af" -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import A type instance F Bool = Int h :: F Bool -> IO () h = print -- D.hs {-# LANGUAGE TemplateHaskell #-} import C import Language.Haskell.TH.Syntax main = h $( return (VarE (Name (OccName "g") (NameG VarName (PkgName "main") (ModName "B")))) ) }}} This does an unsafe coerce: {{{ ezyang at sabre:~/Dev/labs/T13102$ ghc-head --make B.hs D.hs -fforce-recomp [1 of 4] Compiling A ( A.hs, A.o ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling C ( C.hs, C.o ) [4 of 4] Compiling Main ( D.hs, D.o ) Linking D ... ezyang at sabre:~/Dev/labs/T13102$ ./D 8070450533355229282 }}} Clearly, checking consistency on imports is not enough: we must also check up on original names that come by other mechanisms. (Other ways we can end up with identifiers without imports include overloading, see ticket:13102#comment:13. A few things to note about how to fix this: * Currently, type family instances are checked for consistency as we process imports. Template Haskell splices can occur much later in a Haskell file, so we must correspondingly do these checks later. * If we refer to an identifier by synthesizing a name manually, it is as if we imported it. This also means that a reference of this sort implies an implicit import of the defining module (#13102) and we should consider instances from it visible (at the moment, it's not considered visible.) (Actually, with TH, this is a bit tricky, because if we take these semantics, an instance might be visible below a top-level splice, but invisible above it.) * It is probably simplest if the type family compatibility check happens at the end. So we should go ahead and revive idea (2) from https://ghc.haskell.org/trac/ghc/ticket/11062#comment:9 ; if there are overlapping families we should just not reduce the type family. * For wired in things, it's pretty easy to find out if we have an implicit import: if we bang on `checkWiredInTyCon`, that means we intended for the instance to visible; so we should collect all of the TyCons we banged on this way. For TH, this isn't exactly going to work, but maybe we can just track when NameGs get synthesized. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 18:13:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 18:13:32 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.dadaeeb11dfc7a6267618ed442f47631@haskell.org> #13193: Integer (gmp) performance regression? -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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 rwbarton): Interesting. Looks like your test was before Phab:D3034 landed, so maybe that will help some. There was another difference unrelated to integer-gmp when I compared the Core for 7.8 and 7.10, with something getting marked as one-shot in 7.10. I didn't investigate that closely (and I also found it very hard to understand what this benchmark program does). I may take another look later, but unlikely to be in the immediate future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 18:27:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 18:27:29 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.bfacdd9f4bb9a0c060d68257076fdb3d@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): rwbarton: I suspect mreq and FormResult are the similar to ones in my attachment (which are originally from yesod, but stripped out of stuff). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 18:57:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 18:57:54 -0000 Subject: [GHC] #13204: Core Lint error running testsuite with DEBUG way In-Reply-To: <047.381ba5a00f4e3199e228a3db6ee351e7@haskell.org> References: <047.381ba5a00f4e3199e228a3db6ee351e7@haskell.org> Message-ID: <062.023aa940877845c893ecdd49652caf0a@haskell.org> #13204: Core Lint error running testsuite with DEBUG way -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe this was fixed by my top-level strings fix (f5b275a239d2554c4da0b7621211642bf3b10650). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 19:57:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 19:57:50 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.90ca15663ba35c247a018b2fa7af2e78@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Just plain `cabal install aws --allow-newer --with-ghc=...` should do it. N.B. `--allow-newer is quite handy when testing pre-release GHC's against Cabal packages; it tells Cabal to ignore upper bounds on the packages dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 20:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 20:39:23 -0000 Subject: [GHC] #13256: Warn on out-of-range literals in pattern matches too Message-ID: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> #13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | 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: -------------------------------------+------------------------------------- We have these nice warnings for numeric literal expressions that are out of range of their type: {{{ Prelude> 100000000000000000000000000000000 :: Int :1:1: warning: [-Woverflowed-literals] Literal 100000000000000000000000000000000 is out of the Int range -9223372036854775808..9223372036854775807 }}} but nothing for numeric patterns: {{{ Prelude> (\x -> case (x :: Int) of 100000000000000000000000000000000 -> 0) 8 :: Int :3:8: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: p where p is not one of {100000000000000000000000000000000} *** Exception: :3:8-64: Non-exhaustive patterns in case }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 20:48:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 20:48:22 -0000 Subject: [GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals Message-ID: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> #13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | 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: -------------------------------------+------------------------------------- By default (without `NegativeLiterals`) a negated literal `-1` is desugared as `negate (fromInteger 1)`. Hence the existing out-of-range literal warning doesn't trigger for `-1 :: Word`. But we could also recognize the pattern `negate (fromInteger lit)`, and give a warning when `-lit` is out-of-range (for `Word`, this is whenever `lit` is positive). Actually this could apply to signed integer types too: if we recognized `negate (fromInteger lit)` in preference to `fromInteger lit`, we could correctly not warn about `-128 :: Int8`, even when `NegativeLiterals` is not enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 20:48:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 20:48:39 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.6c3607eaf53aa4a735975b862b95a2c8@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I created #13256 and #13257 for the suggestion of "Issue a warning when a negative number is used in a case statement in unsigned context". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:08:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:08:49 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.82f894d53b50ff8c778fa1b607aa3bb8@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 ezyang): * I think there are two possible cases where code change would be necessary (but I don't think any of them actually apply): - If GHC.Exts defined orphans, we should still treat those orphans as visible. But I don't think we have any orphans. Would be good to check. - You are right that one can't define an instance of IsList without importing it, so we should be able to get away without the check. And evidently this doesn't apply if GHC.Exts does have orphans, because that means we can define an instance without importing GHC.Exts * Yes, I guess we have to handle known-key things. Hmm, we don't call `checkWiredInTyCon` for those, so there might be trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:11:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:11:30 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.794c8515a8801366ca5f47a9038793ee@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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 ezyang): Yes, I think that's along the ideas of what we ought to do, although Simon thinks it would be simpler if we didn't do the family instance checks until the very end of the entire module. Template Haskell NameG on an external package which we don't actually depend on is an interesting problem. One possibility is that we should validate these references, and complain if the identifier comes from something we didn't depend on (I guess this is the preload set?) I haven't thought too carefully about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:20:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:20:36 -0000 Subject: [GHC] #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' Message-ID: <046.7f59e0de65f26aa737c47bde12bfd343@haskell.org> #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' -------------------------------------+------------------------------------- Reporter: clinton | 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: -------------------------------------+------------------------------------- Not sure if this is a bug in 'mono-traversable' or GHC but I thought it was worth reporting in any case. GHC head 8.1.20170209 is the version used: {{{ Configuring mono-traversable-1.0.1.1... Preprocessing library mono-traversable-1.0.1.1... [1 of 5] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, .stack-work/dist/x86_64-linux/Cabal-1.25.0.0/build/Data/MonoTraversable.o ) /tmp/stack12856/mono- traversable-1.0.1.1/src/Data/MonoTraversable.hs:144:13: error: • The default type signature for omap: forall (f :: * -> *) a. (Functor f, Element (f a) ~ a, f a ~ mono) => (a -> a) -> f a -> f a does not match its corresponding non-default type signature • When checking the class method: omap :: forall mono. MonoFunctor mono => (Element mono -> Element mono) -> mono -> mono In the class declaration for ‘MonoFunctor’ | 144 | default omap :: (Functor f, Element (f a) ~ a, f a ~ mono) => (a -> a) -> f a -> f a | ^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:28:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:28:51 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.fda6aa00ccd7c540120f3ddce8b6baab@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): What about adding a new function `runRW##` and allowing -1 to be the phase argument to INLINE? Specifically: {{{#!hs {-# LANGAUGE MagicHash #-} import GHC.Prim runRW## :: forall (r1 :: RuntimeRep). (o :: TYPE r) => State# RealWorld -> (# State# RealWorld, o #) -> (# State# RealWorld, o#) runRW## f = f realWorld# {-# INLINE [-1] runRW## #-} }}} with `runRW# f` having the compulsory unfolding {{{#!hs join $j s = f s {-# INLINE [-1] $j #-} in runRW## @ 'PtrRepLifted @ _ ( \s0 -> $j s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:33:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:33:12 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.9bef0d22daa65febf46d2634c1fb4894@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This wouldn’t be a valid use of a join point, would it? You cannot pass join-points in lambdas to arguments. But maybe that points to a solution. Can we somehow tell GHC that the argument of `runRW#` is special in the sense that passing a join-point call there is ok? So to say, a promise that by the time we generate code, the argument will be passed `n` functions and be used in a join-point eligible way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:34:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:34:10 -0000 Subject: [GHC] #13248: Allow an injective type family RHS to be another injective type family In-Reply-To: <044.7f820fc78fab115fd03f04c386b38536@haskell.org> References: <044.7f820fc78fab115fd03f04c386b38536@haskell.org> Message-ID: <059.9bb0228b9f39d3c12608b6e5afdc9921@haskell.org> #13248: Allow an injective type family RHS to be another injective type family -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c22cd7cc28238cf84f90dda9961064f5ea44761d/ghc" c22cd7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c22cd7cc28238cf84f90dda9961064f5ea44761d" testsuite: Add testcase for #13248 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 21:45:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 21:45:31 -0000 Subject: [GHC] #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' In-Reply-To: <046.7f59e0de65f26aa737c47bde12bfd343@haskell.org> References: <046.7f59e0de65f26aa737c47bde12bfd343@haskell.org> Message-ID: <061.d720b46ea47eb8b4e4ce9c07f448d3d9@haskell.org> #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' -------------------------------------+------------------------------------- Reporter: clinton | 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 ezyang): Possibly related to #13249? The default signature check is new so it may very well be picking up a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 22:04:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 22:04:00 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.b5f5425dd50ea9f7542211ff73b82953@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Is the bootstrap time regression due to a bug I introduced in Phab:D2879 that was fixed by rwbarton in Phab:D3070? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 22:09:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 22:09:43 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.9211730b3956f83a34ad7ce87e72e055@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): No they are two different bad regressions. Reid has a spreadsheet which shows how the build time has changed over time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 22:51:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 22:51:44 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.57e2e7ef89caf086ef5a6db744bd7b15@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Reid, Ben, David: might one of you be able to dig into where the 13% build time increase is coming from? The compiler/perf tests suggest that it's not an across-the-board increase in compile time, so perhaps some things are big outliers? Without more insight we are stuck on this, and we can hardly release with such a big step change in build time -- at least not without understanding it. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 22:52:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 22:52:52 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.3df59b1a1b4f1cd3f73adf5379d96851@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, I'll do some preliminary investigations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 22:59:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 22:59:40 -0000 Subject: [GHC] #13259: cross-endian GHC generates invalid .hi files Message-ID: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> #13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- I've reproduced the bug in the following setup: {{{ ./configure \ --enable-unregisterised \ --host=x86_64-pc-linux-gnu \ --target=m68k-unknown-linux-gnu }}} m68k is a 32-bit big-endian machine. {{{ $ LD_BIND_NOW=1 inplace/bin/ghc-stage2 --show-iface libraries/base/dist- install/build/System/IO.hi Magic: Wanted 129742, got 3472490752 magic number mismatch: old/corrupt interface file? (wanted 129742, got 3472490752) $ printf "%08X - %08X\n" 129742 3472490752 0001FACE - CEFA0100 }}} Reverting changeset:fbcef83a3aa130d976a201f2a21c5afc5a43d000 restores .hi loading and ghc-stage2. I'm still not sure what exactly breaks. WORDS_BIGENDIAN looks suspicious. I guess it breaks ghc-stage1 endianness understanding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 9 23:32:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Feb 2017 23:32:41 -0000 Subject: [GHC] #13259: cross-endian GHC generates invalid .hi files In-Reply-To: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> References: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> Message-ID: <060.802c43753a2a082c3780d726f43f5119@haskell.org> #13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => highest * cc: alexbiehl (added) * milestone: => 8.2.1 Comment: I'm marking this as a release blocker as in the worst case we can just revert fbcef83a3aa130d976a201f2a21c5afc5a43d000. I'm not sure exactly what is wrong either, but possibly we could use the new code in the non-crosscompiling case only. Do we know that it's actually faster? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:05:35 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.ad78f5eaa4d525ffda0fb414ba7bd635@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by amindfv): Thanks so much, Simon -- your fix for the #8155 issue will make this much easier to work with in practice! Along with the user doc updates, I've added another unit test, to ensure the behavior from the #8155 backpedal works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:51:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:51:23 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.28e8aab004d3f337c7cb475c9b23fd32@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3115 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * differential: => D3115 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:54:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:54:13 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.eb3eac76f7cb68c69ff931c85fd90276@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): When writing the fix, I noticed that my description of what exactly is the bug is wrong. The `if (size - w > count)` isn't the problem, that's just another infelicity (e.g. it'll make that if you have an 8 K buffer and write 2 K chunks to it, we'll always flush 6 K buffers), which I'll fix too. The real bug is simply that we `flushWriteBuffer` even if `w == 0` (handle buffer is empty). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:55:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:55:55 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.739a7de88c2507224379c5744517e276@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D3115 -------------------------------------+------------------------------------- Changes (by nh2): * differential: D3115 => https://phabricator.haskell.org/D3115 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:56:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:56:11 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.2a1a96a0309c5cdf0d5f7333b1373a7b@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D3117 -------------------------------------+------------------------------------- Changes (by nh2): * differential: => https://phabricator.haskell.org/D3117 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:56:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:56:28 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.9cf40ae78816b96ed99d9b247ee53afa@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D3117 -------------------------------------+------------------------------------- Changes (by nh2): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 00:56:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 00:56:32 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.8c084bfc1a0b824ee1d74a555c98a7fa@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D3115 -------------------------------------+------------------------------------- Changes (by nh2): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 01:17:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 01:17:11 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.b9c1955b56ac4a0aecfd42f52f1cc426@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3115 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: https://phabricator.haskell.org/D3115 => Phab:D3115 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 01:17:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 01:17:28 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.a983f1493a297b848de55c3e4f72f110@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Phab:D3117 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: https://phabricator.haskell.org/D3117 => Phab:D3117 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 01:40:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 01:40:20 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern Message-ID: <047.984d4241873e1562c305a37585f1b95c@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | 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: -------------------------------------+------------------------------------- I don't think this program is meaningful, but it shouldn't cause a panic. {{{#!hs {-# LANGUAGE MagicHash #-} g y = case y of "a"# -> True _ -> False }}} {{{ [1 of 1] Compiling CaseOnString ( x/CaseOnString.hs, x/CaseOnString.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): litValue "a"# }}} The panic is also in at least 7.8, 7.10, and HEAD. `"a"#` has type `Addr#`, and I suppose that if we allow `case` on `Addr#` then it ought to use pointer equality. But the literal `"a"#` has no particular address, so matching against it in a `case` doesn't make sense. So I think we should just disallow unboxed string literals as patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 02:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 02:38:57 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern In-Reply-To: <047.984d4241873e1562c305a37585f1b95c@haskell.org> References: <047.984d4241873e1562c305a37585f1b95c@haskell.org> Message-ID: <062.6378ea7f372d5a3ed71edef864480aca@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 02:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 02:59:10 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.3a7f3f317b1ee67af7c93cba6f263b77@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): Replying to [comment:2 bgamari]: > I'm actually not sure that the effect on compiler performance is all that modest, unfortunately. [[https://perf.haskell.org/ghc/#revision/8d5cf8bf584fd4849917c29d82dcf46ee75dd035|Gipeda]] shows that the build time for GHC itself went up by 13%. While some increase is to be expected, this is quite significant. Are there any obvious knobs that could be adjusted to reduce the amount of work that the join point analysis/simplifier do under `-O1`? The full analysis is great for `-O2`, but I do fear that users will be up in arms if the GHC regression is representative of user code. There isn't anything obvious—the occurrence analyser looks for join points as it goes, and that process should only be a small constant overhead. Nothing in the simplifier (or elsewhere that I can think of) has to work particularly hard to handle join points (or it shouldn't, anyway!). > Also, strangely enough, while the join points work eliminated all allocations from `fannkuch-redux`, the actual runtime of this test might have actually gone up by 8%. I say "might have" since runtime measurements are notoriously unstable, but it does look likely that this is a real regression: the test's runtime is quite long (4 seconds) and 8% is quite a large change. Even if this measurement were off by a factor of two we would want to understand it. Can you shed any light on this, Luke? I haven't seen that jump before, and it's not obvious why it would happen. A quick diff of the dumps shows that the two versions end up with wildly different code, so it may be hard to pin any particular culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 03:38:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 03:38:15 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.265c4d67ad800b59a7bbc0e154cb8593@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The `fannkuch-redux` test is one that can be sensitive to mysterious code alignment effects; see #8279. However the reduction in allocations is so striking that it's worth checking whether something else could have gone wrong here. I'm pretty familiar with `fannkuch-redux`, so I'd be happy to investigate that one as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 04:05:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 04:05:40 -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.e294e3db7ee18f51d827f54b94237cba@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: | -------------------------------------+------------------------------------- Comment (by bgamari): I've spent much of today trying to correlate Ticky's results with the RTS's allocation counters and at this point I strongly suspect that there is a rather large discrepancy. Specifically, I've been trying to track down an apparent regression in `haddock`'s allocations due to Phab:D2038. Here I observe, ||= =||= Ticky's `ALLOC_HEAP_ctr` =||= Ticky's `ALLOC_HEAP_tot` =||= RTS `Bytes allocated` =|| || *before D2038* || 174007560 || 9357869592 || 23809691712 || || *after D2038* || 174243649 || 9365165304 || 27690978448 || That is, while the RTS's `bytes allocated` metric regresses by around 15%, Ticky's allocation counter only appears to regress by ~1%. Moreover, I am unable to find any large regression in the per-closure counters. It's all very unfortunate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 04:09:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 04:09:19 -0000 Subject: [GHC] #12893: Profiling defeats stream fusion when using vector library In-Reply-To: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> References: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> Message-ID: <062.a0f9821beac837c9e12e9e21c5e7ee56@haskell.org> #12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: stream-fusion | profiling Operating System: MacOS X | 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): However, do keep in mind that profiling isn't an all-or-nothing proposition. If you would like to use the profiler it is still possible to (with care) manually insert cost-centers or even enable automatic cost- center insertion for entire (non-performance critical) modules by using the `OPTIONS_GHC` pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 04:48:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 04:48:14 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous In-Reply-To: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> References: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> Message-ID: <061.c43dc599f1e0b8e35f173f2457bc9831@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): What about {{{#!hs default remaining :: (MonadTrans t, Monad m) => t m (Remaining m) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 06:17:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 06:17:06 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver Message-ID: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Since 91c6b1f54aea658b0056caec45655475897f1972 we have generated a set of bindings with each datatype definition which the compiler will refer to when constructing `Typeable` evidence. As described in the commit message, this came with a rather significant performance penalty, especially given that it is paid regardless of whether the code being compiled uses `Typeable`. The type-indexed Typeable implementation (#11011) augments these bindings with additional information allowing the kind of a type of be reconstructing at runtime (#10343). Unfortunately, this further blows up the cost of associated with Typeable binding generation. Some of the testsuite regressions are hard to swallow to say the least. While I'm still working out what can be done to reduce this cost, I do wonder whether the generating these bindings at the time of type definition is so wise. Relatively few users make use of Typeable and the cost is not negligible. Moreover, generating bindings for families of tycons (e.g. unboxed sums, which have thousands of type constructors and promoted data constructors) all at once produces a truly massive amount of code (albeit it only has to be done once). On the other hand, I suppose if Richard's dependent types story comes to fruition then perhaps the weight imposed by generating Typeable bindings at type-definition time might pull its weight. Anyways, just idle reflections. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 06:18:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 06:18:41 -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.9d9faa8d8f4c7e7d74a0c616ccd69886@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: | -------------------------------------+------------------------------------- Comment (by bgamari): Please ignore comment:5; the problem was that I had neglected to pass `-ticky` to the stage1 compiler when it built `base` et al. Consequently a large fraction of the code linked into my executable lacked ticky instrumentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 07:40:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 07:40:41 -0000 Subject: [GHC] #13259: cross-endian GHC generates invalid .hi files In-Reply-To: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> References: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> Message-ID: <060.8d44b47d15f3d5be0bec90ee83fa45ce@haskell.org> #13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 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): D3122 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alexbiehl): * status: new => patch * differential: => D3122 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 08:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 08:32:38 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.f0558f404ced12e4c333a7345285479a@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I think we are done. Please add a Note as suggested on Phab, then Ben can you land this? Thanks for being so patient with this. I think it's been worth it though: the result is much better than were we started. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 08:53:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 08:53:34 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.21b854236846ccdf436260c457c4c6e5@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): All we are doing is generating a bunch of records with strings in them. I wonder why that is so expensive? One possibility is that we could inject them into Core right at the end, perhaps even after `CoreTidy`. Then they would get code generated but not be put in interface files etc. Runtime perf of typeable code would be a little less (no cross module inlining), but hey we are doing dynamic type tests. Instead, we'd need distinctive names so that we knew that if we see `Data.List.Maybe:tyconName` in an interface file unfolding we aren't going to see it in the `Data/List/Maybe.hi`. This is a bit like data constructor workers, I think. Or we could inject them just before `CoreTidy` so they did appear in `.hi` files but didn't clog the optimisation pipeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 08:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 08:54:16 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.21b03e3671b98829e7e4d979fcb32aea@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3123 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 08:55:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 08:55:35 -0000 Subject: [GHC] #10681: Teach GHC to interpret all hs files as two levels of hs-boot files (abstract types only/full types + values) In-Reply-To: <045.0dac7803547af5ada3f670c588d36854@haskell.org> References: <045.0dac7803547af5ada3f670c588d36854@haskell.org> Message-ID: <060.d40b503fef3c7ad8513f911535280ede@haskell.org> #10681: Teach GHC to interpret all hs files as two levels of hs-boot files (abstract types only/full types + values) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack 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 ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 08:58:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 08:58:16 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.1a15253278bb075d8148a196e7a849f2@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: 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): Maybe this proposal cannot be made to work: GHC doesn't accept type families in instance heads (for fairly good reasons). If that's the case, is there really anything interesting one can do with this extension? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:01:17 -0000 Subject: [GHC] #10749: Boot file instances should imply superclasses In-Reply-To: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> References: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> Message-ID: <060.ecc95159179c0ae58dc78099f4e2a690@haskell.org> #10749: Boot file instances should imply superclasses -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack 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 ezyang): * priority: low => normal Comment: Something that I've noticed is that (1) is not consistent with how superclasses work. For example, if I say: `Ord a => a -> a -> Bool`, I DO get an `Eq` instance in scope (because Eq is a superclass of Ord). So in practice, when I'm writing instances for modules in Backpack, I end up having to list a lot of instances, e.g., `Functor`, `Applicative`, `Monad`, `MonadFix`, etc. when, in the source code I was looking at, there was only `MonadFix`. Food for thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:04:13 -0000 Subject: [GHC] #12703: Expand Backpack's signature matching relation beyond definitional equality In-Reply-To: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> References: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> Message-ID: <060.35102b9117b1d329dfe3f12c8aece897@haskell.org> #12703: Expand Backpack's signature matching relation beyond definitional equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang: @@ -41,0 +41,5 @@ + + One particular place this shows up is if you're incrementally Backpack'ing + an interface that has an existing type class. In this case, you might like + to just reexport the methods of the type class and "fill" the imports; but + these methods have the wrong types! (They're not monomorphic enough). New description: Currently, signature matching is done by strict definitional equality. This can be pretty inconvenient in some cases (it is also the only place in the Haskell language that we actually expose definitional equality): **Polymorphism.** This is the obvious one. If I have an implementing function that is more polymorphic than my signature, I have to manually monomorphize it. {{{ unit p where signature H where import Prelude (Int) data String length :: String -> Int unit q where module H(String, length) where -- from Prelude unit r where dependency p[H=q:H] }}} Gives {{{ : error: Identifier ‘Data.Foldable.length’ has conflicting definitions in the module and its hsig file Main module: Data.Foldable.length :: Data.Foldable.Foldable t => forall a. t a -> GHC.Types.Int Hsig file: Data.Foldable.length :: GHC.Base.String -> GHC.Types.Int The two types are different }}} Essentially, you have to monomorphize any functions you want to use. Annoying! One particular place this shows up is if you're incrementally Backpack'ing an interface that has an existing type class. In this case, you might like to just reexport the methods of the type class and "fill" the imports; but these methods have the wrong types! (They're not monomorphic enough). **Quantifier ordering.** Here's a more subtle one: if I don't explicitly specify a type signature, GHC will pick whatever quantifier ordering it wants. Quantifier ordering affects definitional equality. It's actually pretty easy to trigger this, since GHC seems to always pick the reverse of what you'd get if you explicitly specified the type signature: {{{ unit p where signature H where k :: a -> b -> a unit q where module H where k x y = x unit r where dependency p[H=q:H] }}} Fails with: {{{ q.bkp:7:9: error: Identifier ‘q:H.k’ has conflicting definitions in the module and its hsig file Main module: q:H.k :: t2 -> t1 -> t2 Hsig file: q:H.k :: a -> b -> a The two types are different }}} **Constraint relaxation.** In #12679, you might want to define an abstract class which you can use to let implementors pass in type class instances that they might need. But you often end up in situations where the real implementations of your functions require less constraint than the signature specifies; for example, you might write `insert :: Key k => k -> a -> Map k a -> Map k a`, but if Map is an association list and just appends the new value onto the front of the list, no Eq constraint needed! There goes another impedance matching binding. **Type families.** Type family applications aren't reduced when deciding definitional equality. {{{ {-# LANGUAGE TypeFamilies #-} unit p where signature H where f :: Int unit q where module H where type family F type instance F = Int f :: F f = 2 unit r where dependency p[H=q:H] }}} Gives {{{ q.bkp:11:9: error: Identifier ‘q:H.f’ has conflicting definitions in the module and its hsig file Main module: q:H.f :: q:H.F Hsig file: q:H.f :: GHC.Types.Int The two types are different }}} **Discussion.** It's instructive to consider what the impacts of this sort of relaxation would have on hs-boot files. Some of the equalities that users expect in the source language have operational impact: for example, the ordering of constraints affects the calling convention of the function in question. So there would need to be an impedance matching binding to reorder/drop constraints to match the defining function. We already do an impedance matching of this sort with dictionary functions; this would be a logical extension. Thus, a signature would have to monomorphize, coerce, etc--whatever it needs to show the matching holds. I think this is quite plausible, although it would require rewriting this chunk of code. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:04:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:04:44 -0000 Subject: [GHC] #12703: Expand Backpack's signature matching relation beyond definitional equality In-Reply-To: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> References: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> Message-ID: <060.31a07f08dc94eed7a240962175c0f313@haskell.org> #12703: Expand Backpack's signature matching relation beyond definitional equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2928 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * differential: => Phab:D2928 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:05:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:05:31 -0000 Subject: [GHC] #13067: Abstract closed type families don't work with Backpack In-Reply-To: <045.d425a29a2949d9aaec22378dc47e66ba@haskell.org> References: <045.d425a29a2949d9aaec22378dc47e66ba@haskell.org> Message-ID: <060.11b3eacfd46ed99268ab926a2a811b19@haskell.org> #13067: Abstract closed type families don't work with Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2928 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * differential: => Phab:D2928 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:06:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:06:53 -0000 Subject: [GHC] #13069: hs-boot files permit default methods in type class (but don't typecheck them) In-Reply-To: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> References: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> Message-ID: <060.3b4e72832284cbc71949b61aef3ce8df@haskell.org> #13069: hs-boot files permit default methods in type class (but don't typecheck them) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot 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 ezyang): The corresponding version of this bug with hsig files was fixed with #13041. So it's just an hs-boot bug now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:07:05 -0000 Subject: [GHC] #13149: Giving Backpack a Promotion In-Reply-To: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> References: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> Message-ID: <060.4e657a8c1b6df76bc3ccd89ce6818ad9@haskell.org> #13149: Giving Backpack a Promotion -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.1 Resolution: | Keywords: backpack 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 ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:51:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:51:29 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.3558fc860ba315c50ff0bfedc2117551@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Can we somehow tell GHC that the argument of runRW# is special in the sense that passing a join-point call there is ok? That would be horribly ad-hoc. We need a better way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 09:52:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 09:52:34 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it reduces away Message-ID: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> #13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- GHC rejects the following program: {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module F where type family F a type instance F Int = Int -> Int instance Show (F Int) where show _ = "fun" }}} But this doesn't seem fundamentally problematic to me: at the instance declaration, we know that F Int will reduce, and after that reduction there isn't any problem with the instance. Here's a less restrictive instance head test: first, we reduce type families as much as possible. Then, if there are still leftover non- reducing type families, reject the instance. After having typed this up, I have realized that I don't actually need this feature. But I'm filing it here for posterity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:17:41 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.1e9f5c42e0bd898a1015bd2237c974a6@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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 simonpj): Here's a summary. === Instance providers === * Define an '''instance provider''' thus: a module A is an instance provider for M if the class and family instances in A, and those of A's instance providers, are visible in M. * An '''orphan instance provider''' for M is an instance provider for M that is also an orphan module. Instance providers come from three places: * M's direct imports are clearly import providers for M. * Less obviously, the use of a wired-in `TyCon` to deal with built-in syntax (e.g. overloaded lists) may add a new instance provider that was not (transitively) imported. A particular case is `GHC.Exts`. * Also less obviously, if Template Haskell splices in a definition like {{{ f = P.Q.g }}} then `P.Q` becomes an instance provider, because the family instances available there may have been used to typecheck `P.Q.g`. === Consistency checking === We must do family-instance consistency checks for the transitive closure of all M's instance providers. The easiest place to do this is right at the end of type checking, when we have a complete set of instance providers to check. The only downside is that, in the meantime, we could have inconsistent type-family instances, and we would need to account for that in type-family lookup (for example by returning not-found). === Instance lookup === Generally, we vigorously load instances into a single instance environment in the External Package State. But which ones are visible? Answer: the instance providers. We can use this to filter out the instance(s) we match on. But we need only check against the orphan instance providers because if the instance is in a no-orphan module X, then X must be in the instance providers else how could we be looking up that particular predicate? === Tracking instance providers === We can track the instance providers by accumulating * M's direct imports * Modules loaded by `checkWiredInTyCon` * Ditto for Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:19:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:19:35 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.ade1057f5c313404e14ccece59af2a1f@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): > In any case, since #13251 is its own ticket, I'll continue here with the short-term plan of using the same rules for type family instance visibility as for class instance visibility. Yes that's fine I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:31:10 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.f43afed9f9b45c6efd664dde1b157aa3@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr 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): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:37:04 -0000 Subject: [GHC] #11668: SPEC has a runtime cost if constructor specialization isn't performed In-Reply-To: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> References: <046.e1cd9cfedab3c62d2fdad4e2ab3e91e0@haskell.org> Message-ID: <061.042fca5810b9aabcdb1bc3e8fe5350b1@haskell.org> #11668: SPEC has a runtime cost if constructor specialization isn't performed -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: SpecConstr 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): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:37:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:37:25 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.00b2b847e092de01466bdb0824303688@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr 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): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:42:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:42:52 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.d93c51e79420b43492f791aa2af93e88@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | 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:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"258c719599f78178c75b58d9c49e10e498cb7c48/ghc" 258c719/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="258c719599f78178c75b58d9c49e10e498cb7c48" TH-spliced class instances are pretty-printed incorrectly post-#3384 Summary: The HsSyn prettyprinter tests patch 499e43824bda967546ebf95ee33ec1f84a114a7c broke the pretty-printing of Template Haskell-spliced class instances. Test Plan: ./validate Reviewers: RyanGlScott, austin, goldfire, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3043 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 10:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 10:46:13 -0000 Subject: [GHC] #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 In-Reply-To: <050.b044bfecf56f5eb671b9f81c21e00b95@haskell.org> References: <050.b044bfecf56f5eb671b9f81c21e00b95@haskell.org> Message-ID: <065.88a93ad3ddab7803412370eeb8429585@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3043 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 12:03:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 12:03:38 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.e631255a9e530b8f920ce03c0811d6c5@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record, I've never been totally convinced by the "generate Typeable stuff at declaration time" approach. As noted above, there is a shared cost. Do we have any program that shows a concrete speed boost by the new design? Yes, the new design seems like `Typeable`-heavy code would run faster, but it would be lovely to verify this fact and be able to quantify it. Once there are dependent types, this issue does not really change. Yes, users could effectively use `Typeable` without writing the word `Typeable` in their programs, but they would still need to use runtime type tests to trigger any of this machinery. So I would consider this orthogonal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 12:24:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 12:24:43 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.d0590c94403220a74ce253e0082fd01d@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have no fixed objection to doing it on the fly. But then we'd probably want some way to avoid repeatedly generating the same stuff, some kind of on-the-fly CSE.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 13:23:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 13:23:13 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.8b37d7f1edc2d3e17d385d22029a60d2@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I can't reproduce this with HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 13:34:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 13:34:23 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.3cd5b5b558b8564a7141b8c945c1465d@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > That would be horribly ad-hoc. We need a better way. *shrug* no more than the the one-shot hack we had for `build` before we came up with a proper analysis that could figure out that information. I guess the difference here is that we don’t expect random user-defined functions to have this property. The discussion of eta-expanding the argument of `runRW#` has been interrupted by comment:4, we should consider that thought again. Maybe one of the variants in comment:1 nail it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 14:18:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 14:18:58 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.7c82611c37b73524a766643de7e4e2b4@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollu): I would like to take this up, do I simply assign it to myself? thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 14:27:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 14:27:02 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.c9aed16c220302e3bff667e6ee418a6c@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yup, go ahead. This task probably just involves replacing these hardcoded format specifiers with the correct ones from https://github.com/ghc/ghc/blob/master/includes/stg/Types.h. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:25:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:25:49 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.078d55c254cf69e4df373ef6cc09518f@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Can we do it like specializations: Create on the fly the first time we need them, but use an existing one if any dependency already created them? (Maybe this is what Simon means by on-the-fly CSE). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:34:53 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind In-Reply-To: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> References: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> Message-ID: <065.203bbb306005dead563a77da86ae462a@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.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): Phab:D3022 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"283a346586e5bf711ecd8cc61263d87771f8f744/ghc" 283a3465/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="283a346586e5bf711ecd8cc61263d87771f8f744" Prevent Template Haskell splices from throwing a spurious TypeInType error Summary: There was a rather annoying corner case where splicing poly-kinded Template Haskell declarations could trigger an error muttering about `TypeInType` not being enabled, whereas the equivalent non-TH code would compile without issue. This was causing by overzealous validity check in the renamer, wherein failed to distinguish between two different `Exact` names with the same `OccName`. As a result, it mistakenly believed some type variables were being used as both type and kind variables simultaneously! Ack. This avoids the issue by simply disabling the aforementioned validity check for Exact names. Fixes #12503. Test Plan: ./validate Reviewers: austin, bgamari, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:37:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:37:39 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.6336be3149207309a8823dd926cf8598@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): re Simon PJ's comment 17, would it be relatively easy to do this with the llvm compiler? AFAIK opt and llc don't seem to have the appropriate options but clang has -Os and -Oz (see [https://clang.llvm.org/docs/CommandGuide/clang.html]) so I would hope it wouldn't be too hard to do in the Haskell llvm compiler. Also wrt llvm there is mention of alignment here [http://llvm.org/docs/Frontend/PerformanceTips.html]. I'm sure most people interested in the llvm compiler are aware of this doc but I thought I may as well mention it to be complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:39:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:39:05 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind In-Reply-To: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> References: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> Message-ID: <065.a79d7ec64723388e28c1c31b28cada0a@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | tests/th/T12503 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3022 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => tests/th/T12503 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:52:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:52:48 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.0e006f03ec74c37bed11872d796ba19a@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Interesting; I have been able to reproduce this pretty reliably. I'll try to have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:54:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:54:08 -0000 Subject: [GHC] #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' In-Reply-To: <046.7f59e0de65f26aa737c47bde12bfd343@haskell.org> References: <046.7f59e0de65f26aa737c47bde12bfd343@haskell.org> Message-ID: <061.e0d0ce0d5d8ba00890581e2675be16fe@haskell.org> #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' -------------------------------------+------------------------------------- Reporter: clinton | 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: #13249 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #13249 Comment: This is expected behavior. GHC 8.2 tightened up validity checking for default type signatures. This catches many things which are just plain type incorrect (e.g., see #12918). A consequence of this is that you can't write default type signatures quite as liberally as before, but luckily, it's an extremely easy fix: {{{#!hs class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono default omap :: (Functor f, Element (f a) ~ a, f a ~ mono) => (Element mono -> Element mono) -> mono -> mono omap = fmap {-# INLINE omap #-} }}} The benefit is now the connection between the default and non-default type signatures is much clearer. That is, the default type signature is exactly the same as the non-default one, just with more constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 15:59:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 15:59:51 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.c05d1fa42f998ec137114226ce96ef4a@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | 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 RyanGlScott): * priority: normal => highest * milestone: => 8.2.1 Comment: I'd like to make one last push on this before the 8.2 release, as using 4 GB of extra memory is really unfortunate. Feel free to change the milestone if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 16:02:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 16:02:42 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it reduces away In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.57d2f8ebb07d1e33ddc80a9fd09d390b@haskell.org> #13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Perhaps we should guard the "first, we reduce type families as much as possible" step with the `TypeSynonymInstances` extension (which is implied by `FlexibleInstances`, apparently). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 16:07:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 16:07:46 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.c2c9f72c93d056db8959b21d5920e31c@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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): This plan sounds generally good. Nitpick: > Less obviously, the use of a wired-in `TyCon` to deal with built-in syntax (e.g. overloaded lists) may add a new instance provider that was not (transitively) imported. A particular case is `GHC.Exts`. The things involved in overloaded lists are `fromListN` and the `IsList` type class, both of which are known-key things, not wired-in. (The built- in list type is not the issue here.) Then "Tracking instance providers" needs to include this case as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 16:32:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 16:32:55 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.e8c79c7cd1118c1fde3b97a48ae29dea@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): As far as I've tested, changing spaces in irrelevant places, forces recompilation of files which import the module when the files use TH. I'd say in the current state of affairs there is no danger of ignoring a change, but rather unnecessary recompilation might happen. Regarding the possibility of includes in the C code which changes, it won't be detected in the same way that reading a file with `runIO` isn't detected. For this cases, there is [https://www.stackage.org/haddock/lts-7.19/template-haskell-2.11.0.0 /Language-Haskell-TH-Syntax.html#v:addDependentFile addDependentFile] to let GHC know of the dependency. I'm afraid it is not easy to call `addDependentFile` in `addCStub` because identifying the relevant files is difficult if they are conditionally included (i.e. between `#if` and `#endif`). On the otherhand, it would be ok to ask the frameworks producing the C code to call `addDependentFile` as necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 17:39:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 17:39:03 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.d9eeccda172d34f29b36ea9794f51a61@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I had an idea in mind on how we might do better for `addModCStub` than we can for `runIO`, but it depends on what GHC actually does with the C sources eventually (I don't know what it does): If GHC invokes a plain `gcc` or `cc` or `CC` or whatever, then all bets are off and we can't do better. But if it can separate the C preprocessor invocation and the C compiler invocation, then we could fully preprocess the C code (which expands all includes) and hash that into the interface file, allowing us to notice when included header files change. This is better than having to write that logic ourselves in TH based on `addDependentFile`, because one cannot in TH query what C preprocessor and flags GHC will invoke. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 18:06:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 18:06:55 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.05a5558cc565a49f81d3bd600d0247e9@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Suppose we compile this module. {{{ module A where do addCStub "#include \"header.h\"" return [] }}} How does GHC know to recompile `A.hs` when `header.h` changes. Yes, the hash in `A.hi` includes the old contents in `header.h`, but that doesn't seem to cause GHC to notice that `header.h` changed. For the use case of inline-c, `addCStub` doesn't need to do more. The user won't call it directly. But if you know of other use cases it would be great to learn of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 18:10:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 18:10:50 -0000 Subject: [GHC] #13263: cant derive functor on function newtype with unboxed tuple result Message-ID: <045.bcb05b59c86f5ba011e078b2a85e6c7f@haskell.org> #13263: cant derive functor on function newtype with unboxed tuple result -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I'm not sure if this is a bug or a feature request, but i have a simple example that I think should work with deriving functor but falls over {{{ {-# LANGUAGE ScopedTypeVariables, BangPatterns, UnboxedTuples, MagicHash, GADTs #-} {-# LANGUAGE DeriveFunctor #-} module Test where newtype Eww a = Ew# (Int -> (# a, Int #)) deriving (Functor) }}} the error i get is {{{ src/System/Random/SplitMix/Internal.hs:88:13: error: • The constructor ‘(#,#)’ should have 2 arguments, but has been given 4 • In the pattern: (#,#) a1 a2 a3 a4 In a case alternative: ((#,#) a1 a2 a3 a4) -> (#,#) ((\ b2 -> b2) a1) ((\ b3 -> b3) a2) (f a3) ((\ b4 -> b4) a4) In the expression: case b5 of { ((#,#) a1 a2 a3 a4) -> (#,#) ((\ b2 -> b2) a1) ((\ b3 -> b3) a2) (f a3) ((\ b4 -> b4) a4) } When typechecking the code for ‘fmap’ in a derived instance for ‘Functor Eww’: To see the code I am typechecking, use -ddump-deriv }}} and the dumped deriving is {{{ [1 of 1] Compiling System.Random.SplitMix.Internal ( src/System/Random/SplitMix/Internal.hs, /Users/carter/WorkSpace/projects/active/random-hs/dist- newstyle/build/random-2.0.0.0/build/System/Random/SplitMix/Internal.o ) ==================== Derived instances ==================== Derived instances: instance GHC.Base.Functor System.Random.SplitMix.Internal.Eww where GHC.Base.fmap f_a4Vn (System.Random.SplitMix.Internal.Ew# a1_a4Vo) = System.Random.SplitMix.Internal.Ew# ((\ b6_a4Vp b7_a4Vq -> (\ b5_a4Vr -> case b5_a4Vr of { ((#,#) a1_a4Vs a2_a4Vt a3_a4Vu a4_a4Vv) -> (#,#) ((\ b2_a4Vw -> b2_a4Vw) a1_a4Vs) ((\ b3_a4Vx -> b3_a4Vx) a2_a4Vt) (f_a4Vn a3_a4Vu) ((\ b4_a4Vy -> b4_a4Vy) a4_a4Vv) }) (b6_a4Vp ((\ b1_a4Vz -> b1_a4Vz) b7_a4Vq))) a1_a4Vo) GHC.Generics representation types: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 18:26:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 18:26:53 -0000 Subject: [GHC] #13263: cant derive functor on function newtype with unboxed tuple result In-Reply-To: <045.bcb05b59c86f5ba011e078b2a85e6c7f@haskell.org> References: <045.bcb05b59c86f5ba011e078b2a85e6c7f@haskell.org> Message-ID: <060.74552af1ea6fbc7234ee35ef0e4fa36a@haskell.org> #13263: cant derive functor on function newtype with unboxed tuple result -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #12399 Comment: Duplicate of #12399; should be fixed in 8.0.2 already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 19:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 19:12:32 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.b4fab4791a8f95db43c9ef20dc339407@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): An initial report. I collected timing information from validation builds of the "Join points" commit and its parent commit, each built twice using ghc-8.0.2 and then a perf build of the same commit as the bootstrapping compiler (for reasons to become clear below). I have only looked at the timing results for a few modules so far. Here are the times for everyone's favorite module, `DynFlags.hs`. {{{ stage1 build: bootstrapped by mutator CPU seconds ghc-8.0.2 63s ghc-HEAD-before-join 63s ghc-HEAD-after-join 67s stage2 build: ghc-HEAD-before-join 150-154s ghc-HEAD-after-join 209-213s }}} Observations: * Performance of the perf build (used as the bootstrapping compiler, for the stage1 build of `DynFlags`) may have regressed by a few percent with join points. For now this is looking at the time for just one module, so I wouldn't take that number very seriously. * The time it took the stage1 compiler to perform the stage2 build of `DynFlags` increased by around 40% with the join point change. But, these numbers are both MUCH larger than the time it took to do the stage1 build of `DynFlags`. There are a few possible causes: - The stage1 compiler is built with only `-O`, unlike the perf build that produced the bootstrapping compiler, which built with `-O2`. - The stage1 compiler is built with `-DDEBUG`, so it contains extra sanity checks. - The stage2 compiler is built with `-dcore-lint`, so additional extra checks are being done during the stage2 build. - Something else about the build could be different between the two stages, like the values of CPP macros. I think this is unlikely to be the cause in this case. One of these points seems to have gotten much worse with join points. The good news is that, according to preliminary results, the performance of the perf (i.e., release) build of the compiler seems to be minimally affected. And if the performance regression is in `-dcore-lint`, for example, it may be easy to track down and eliminate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 19:26:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 19:26:52 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.d5cfb4b7fd9529ae688fed27c96e26d7@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Another data point: The total time it to finish the stage1 build (which does include some time spent not in ghc, like running configure scripts) increased from 1208s to 1272s when moving from `ghc-HEAD-before-join` to `ghc-HEAD-after-join` as the bootstrapping compiler, an increase of 5.3%. That's roughly consistent with the 6% increase in `DynFlags.hs` build time mentioned in the previous comment. Still not wonderful, but also not nearly as bad as the total build time regression would seem to indicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 19:55:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 19:55:21 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens Message-ID: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.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: -------------------------------------+------------------------------------- While testing characterizing the performance impact of the Typeable branch (`wip/ttypeable`) against Hackage packages I have found that `lens` manages to break the `(->)` kind-generalization patch. Specifically, `TcCanonical.can_eq_nc` induces a panic by `tcRepSplitTyApp_maybe` during compilation of `Control.Lens.Traversal.holesOf`, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170207 for x86_64-unknown-linux): tcRepSplitTyConApp_maybe ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] c_alzb[tau:5] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1188:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1192:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1456:5 in ghc:TcType tcRepSplitTyConApp_maybe, called at compiler/typecheck/TcCanonical.hs:617:25 in ghc:TcCanonical }}} The last thing emitted by tc-trace is, {{{ can_eq_nc False [WD] hole{alyP} {0}:: (p_alyn[tau:5] :: TYPE p_alym[tau:5]) GHC.Prim.~# (cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] :: *) nominal equality ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] -> c_alzb[tau:5] p_alyn[tau:5] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] }}} While I haven't yet fully reduced the reproducer to a standalone module, replacing `Control.Lens.Traversal` in a `lens` working tree is sufficient, {{{#!hs {-# LANGUAGE Rank2Types #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Control.Lens.Traversal where import Control.Category import Control.Lens.Internal.Bazaar import Control.Lens.Internal.Context import Control.Lens.Internal.Indexed import Data.Tagged import Prelude hiding ((.),id) type Over p f s t a b = p a (f b) -> s -> f t holesOf :: forall p s t a. Conjoined p => Over p (Bazaar p a a) s t a a -> s -> [Pretext p a a t] holesOf l s = unTagged ( conjoined (Tagged $ let f [] _ = [] f (x:xs) g = Pretext (\xfy -> g . (:xs) <$> xfy x) : f xs (g . (x:)) in f (ins b) (unsafeOuts b)) (Tagged $ let f [] _ = [] f (wx:xs) g = Pretext (\wxfy -> g . (:Prelude.map extract xs) <$> cosieve wxfy wx) : f xs (g . (extract wx:)) in f (pins b) (unsafeOuts b)) :: Tagged (p a b) [Pretext p a a t] ) where b = l sell s }}} More specifically, {{{ $ git clone git://github.com/bgamari/hashable $ git clone git://github.com/ekmett/comonad $ git clone git://github.com/ekmett/semigroupoids $ git clone git://github.com/ekmett/lens $ cabal install ./comonad ./lens ./semigroupoids ./hashable --with- ghc=`pwd`/inplace/bin/ghc-stage2 --allow-newer=base,template- haskell,primitive,ghc-prim --disable-library-profiling -j1 --ghc- options='-v -ddump-to-file -ddump-tc-trace' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 19:55:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 19:55:50 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.de3f85df9b3eb0a835b492fb0f990f1e@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bollu Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollu): * owner: => bollu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 19:59:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 19:59:16 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.1a0a34fcad179d9c110f42d47a384434@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 bgamari): Here is a standalone reproducer, {{{#!hs {-# LANGUAGE Rank2Types #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Control.Lens.Traversal where import Control.Category import Prelude hiding ((.),id) type Over p f s t a b = p a (f b) -> s -> f t newtype Bazaar p a b t = Bazaar { runBazaar :: forall f. Applicative f => p a (f b) -> f t } newtype Pretext p a b t = Pretext { runPretext :: forall f. Functor f => p a (f b) -> f t } newtype Tagged s b = Tagged { unTagged :: b } class Conjoined p where holesOf :: forall p s t a. Conjoined p => Over p (Bazaar p a a) s t a a -> s -> [Pretext p a a t] holesOf l s = unTagged ( conjoined (Tagged $ let f [] _ = [] f (x:xs) g = Pretext (\xfy -> g . (:xs) <$> xfy x) : f xs (g . (x:)) in f (ins b) (unsafeOuts b)) (Tagged $ let f [] _ = [] f (wx:xs) g = Pretext (\wxfy -> g . (:Prelude.map extract xs) <$> cosieve wxfy wx) : f xs (g . (extract wx:)) in f (pins b) (unsafeOuts b)) :: Tagged (p a b) [Pretext p a a t] ) where b = l sell s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:09:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:09:36 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.e19ed04b1677a6888c8b7b27a28a35a6@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "Traversal.hs" added. Standalone reproducer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:10:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:10:28 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.572b4eefa3d6fe4d4386958d7b079574@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "Traversal.dump-tc-trace.xz" added. tc-trace output from compilation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:13:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:13:43 -0000 Subject: [GHC] #13259: cross-endian GHC generates invalid .hi files In-Reply-To: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> References: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> Message-ID: <060.9539782e429c4d9de834d6aa1768bad3@haskell.org> #13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 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): Phab:D3122 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: D3122 => Phab:D3122 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:27:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:27:41 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.9b8b056e0b44ead3ad8d1852948e6243@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 bgamari: @@ -40,49 +40,0 @@ - - While I haven't yet fully reduced the reproducer to a standalone module, - replacing `Control.Lens.Traversal` in a `lens` working tree is sufficient, - {{{#!hs - {-# LANGUAGE Rank2Types #-} - {-# LANGUAGE FlexibleContexts #-} - {-# LANGUAGE FlexibleInstances #-} - {-# LANGUAGE ScopedTypeVariables #-} - - module Control.Lens.Traversal where - - import Control.Category - import Control.Lens.Internal.Bazaar - import Control.Lens.Internal.Context - import Control.Lens.Internal.Indexed - import Data.Tagged - import Prelude hiding ((.),id) - - type Over p f s t a b = p a (f b) -> s -> f t - - holesOf :: forall p s t a. Conjoined p => Over p (Bazaar p a a) s t a a -> - s -> [Pretext p a a t] - holesOf l s = unTagged - ( conjoined - (Tagged $ let - f [] _ = [] - f (x:xs) g = Pretext (\xfy -> g . (:xs) <$> xfy x) : f xs (g . - (x:)) - in f (ins b) (unsafeOuts b)) - (Tagged $ let - f [] _ = [] - f (wx:xs) g = Pretext (\wxfy -> g . (:Prelude.map extract xs) <$> - cosieve wxfy wx) : f xs (g . (extract wx:)) - in f (pins b) (unsafeOuts b)) - :: Tagged (p a b) [Pretext p a a t] - ) where b = l sell s - }}} - - More specifically, - {{{ - $ git clone git://github.com/bgamari/hashable - $ git clone git://github.com/ekmett/comonad - $ git clone git://github.com/ekmett/semigroupoids - $ git clone git://github.com/ekmett/lens - $ cabal install ./comonad ./lens ./semigroupoids ./hashable --with- - ghc=`pwd`/inplace/bin/ghc-stage2 --allow-newer=base,template- - haskell,primitive,ghc-prim --disable-library-profiling -j1 --ghc- - options='-v -ddump-to-file -ddump-tc-trace' - }}} New description: While testing characterizing the performance impact of the Typeable branch (`wip/ttypeable`) against Hackage packages I have found that `lens` manages to break the `(->)` kind-generalization patch. Specifically, `TcCanonical.can_eq_nc` induces a panic by `tcRepSplitTyApp_maybe` during compilation of `Control.Lens.Traversal.holesOf`, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170207 for x86_64-unknown-linux): tcRepSplitTyConApp_maybe ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] c_alzb[tau:5] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1188:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1192:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1456:5 in ghc:TcType tcRepSplitTyConApp_maybe, called at compiler/typecheck/TcCanonical.hs:617:25 in ghc:TcCanonical }}} The last thing emitted by tc-trace is, {{{ can_eq_nc False [WD] hole{alyP} {0}:: (p_alyn[tau:5] :: TYPE p_alym[tau:5]) GHC.Prim.~# (cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] :: *) nominal equality ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] -> c_alzb[tau:5] p_alyn[tau:5] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:40:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:40:35 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.b294a40cfd847a2b1a0b2770647b6257@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 bgamari: @@ -1,1 +1,1 @@ - While testing characterizing the performance impact of the Typeable + While characterizing the performance impact of the Typeable New description: While characterizing the performance impact of the Typeable branch (`wip/ttypeable`) against Hackage packages I have found that `lens` manages to break the `(->)` kind-generalization patch. Specifically, `TcCanonical.can_eq_nc` induces a panic by `tcRepSplitTyApp_maybe` during compilation of `Control.Lens.Traversal.holesOf`, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170207 for x86_64-unknown-linux): tcRepSplitTyConApp_maybe ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] c_alzb[tau:5] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1188:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1192:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1456:5 in ghc:TcType tcRepSplitTyConApp_maybe, called at compiler/typecheck/TcCanonical.hs:617:25 in ghc:TcCanonical }}} The last thing emitted by tc-trace is, {{{ can_eq_nc False [WD] hole{alyP} {0}:: (p_alyn[tau:5] :: TYPE p_alym[tau:5]) GHC.Prim.~# (cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] :: *) nominal equality ([] |> <*>_N ->_N Sym {alzj}) a_alzd[tau:5] -> c_alzb[tau:5] p_alyn[tau:5] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] cat_alyK[tau:6] b_alyM[tau:6] c_alyN[tau:6] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:55:02 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.937ac487b7bbebcc14566fddc4a86d4c@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | 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 RyanGlScott): I've independently verified that 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060 caused this regression (at least on `Store-Random.hs`, which I believe is representative of `store`'s compilation regression as a whole). Furthermore, I discovered something interesting. I tweaked `StoreImpl.hs` and `Store-Random.hs` a little such that: 1. `StoreImpl.hs` no longer uses `DefaultSignatures` 2. `Store-Random.hs` now explicitly defines all of its instance methods. That is, `Store-Random.hs` contains these lines: {{{#!hs instance Store ModName instance Store Name instance Store NameFlavour instance Store Type instance Store TyVarBndr instance Store NameSpace instance Store PkgName instance Store OccName instance Store TyLit }}} I tweaked it to be this instead: {{{#!hs instance Store ModName where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store Name where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store NameFlavour where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store Type where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store TyVarBndr where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store NameSpace where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store PkgName where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store OccName where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} instance Store TyLit where size = genericSize peek = genericPeek poke = genericPoke {-# INLINE size #-} {-# INLINE peek #-} {-# INLINE poke #-} }}} I then ran `-dshow-passes` on this program using a pre- 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060 GHC and a post- 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060 GHC. On the original `Store-Random.hs` program: * Pre-54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060: {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 12,859, types: 119,332, coercions: 72,859} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store]: finished in 236.00 milliseconds, allocated 252.916 megabytes *** Simplifier [Store]: Result size of Simplifier iteration=1 = {terms: 40,398, types: 205,815, coercions: 109,233} }}} * Post-54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060: {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 12,859, types: 119,332, coercions: 72,859} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store]: finished in 160.00 milliseconds, allocated 252.680 megabytes *** Simplifier [Store]: Result size of Simplifier iteration=1 = {terms: 59,073, types: 286,228, coercions: 152,155} }}} On the tweaked `Store-Random.hs` program: * Pre-54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060: {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store2]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 12,796, types: 119,305, coercions: 72,832} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store2]: finished in 156.00 milliseconds, allocated 252.064 megabytes *** Simplifier [Store2]: Result size of Simplifier iteration=1 = {terms: 58,888, types: 283,015, coercions: 149,870} }}} * Post-54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060: {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store2]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 12,796, types: 119,305, coercions: 72,832} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Store2]: finished in 176.00 milliseconds, al located 252.076 megabytes *** Simplifier [Store2]: Result size of Simplifier iteration=1 = {terms: 58,888, types: 283,015, coercions: 149,870} }}} Notice that in the tweaked `Store-Random.hs`, there is no difference before and after 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060. While this consistency is nice, the resulting program size is the same as the original program post-54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060, so this certainly didn't fix the bug—it just made it easier to see in the source program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:55:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:55:38 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.b2ec8c88d34c52066553a276060fa695@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:15 facundo.dominguez]: > How does GHC know to recompile `A.hs` when `header.h` changes. This could be added with the approach I tried to describe in my last comment: * GHC sees `addCStub mystring` * Instead of passing `mystring` to e.g. `gcc` to generate an object file, it could pass it to `gcc -E` to generate a fully preprocessed C source code string `mycppdstring` that has all `#include`s expanded. We'd add the hash of `mycppdstring` to the `.hi` file. Please let me know if this makes clearer what I mean. That's outside of the design goals of your ticket though, so probably this enhancement should go into a different ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 20:59:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 20:59:07 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.f6b13da740099299944a3c8ee57e70df@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | 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 RyanGlScott): * cc: simonpj (added) Comment: The question now is: how was GHC generating default instance methods prior to 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060? Perhaps there's a way we could go back to the way the code was generated while preserving the typechecking benefits of 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060. Simon, do you recall how this worked prior to 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060? Unfortunately, `-ddump-deriv` didn't show the generated code for default instance methods prior to 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060, so it's hard for me to figure out what happened before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:15:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:15:24 -0000 Subject: [GHC] #13132: Compilation fails with a panic: get_op runContT In-Reply-To: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> References: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> Message-ID: <062.fdebb362f34080a74104ff02dc5f02a9@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_compile/T13132, | overloadedrecflds/should_fail/T13132_duplicaterecflds Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985, Wiki Page: | Phab:D3126 -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * testcase: rename/should_compile/T13132 => rename/should_compile/T13132, overloadedrecflds/should_fail/T13132_duplicaterecflds * differential: Phab:D2985 => Phab:D2985, Phab:D3126 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:18:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:18:50 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.45d6458eb82c33b4ed0cb7319780861d@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj, goldfire (added) Comment: It appears that replacing the `tcRepSplitTyApp_maybe` callsite in `can_eq_nc'` with a variant which returns `Nothing` instead of panicking allows compilation to proceed, {{{#!hs -- Try to decompose type constructor applications -- Including FunTy (s -> t) can_eq_nc' _flat _rdr_env _envs ev eq_rel ty1 _ ty2 _ | Just (tc1, tys1) <- tcRepSplitTyConApp_maybe' ty1 , Just (tc2, tys2) <- tcRepSplitTyConApp_maybe' ty2 , not (isTypeFamilyTyCon tc1) , not (isTypeFamilyTyCon tc2) = canTyConApp ev eq_rel tc1 tys1 tc2 tys2 }}} Where `tcRepSplitTyConApp_maybe'` is the variant described above. While I'm far from convinced that this is the right, it does seem plausible. Afterall, the failing invocation involves a `FunTy` and an `AppTy`, so the guards really should just fail. It would be nice to hear Simon or Richard's opinion on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:21:21 -0000 Subject: [GHC] #12243: RebindableSyntax and OverloadedLabels In-Reply-To: <048.6e564fb4c32d0e67f5680b5b6de4225b@haskell.org> References: <048.6e564fb4c32d0e67f5680b5b6de4225b@haskell.org> Message-ID: <063.accfbb122406c510ef27cd4263742083@haskell.org> #12243: RebindableSyntax and OverloadedLabels -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: adamgundry Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | overloadedrecflds/should_run/T12243 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2708 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * testcase: => overloadedrecflds/should_run/T12243 * differential: => Phab:D2708 Comment: I've implemented this as part of my reworking of `OverloadedLabels` described in https://github.com/ghc-proposals/ghc-proposals/pull/6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:22:50 -0000 Subject: [GHC] #11672: Poor error message In-Reply-To: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> References: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> Message-ID: <064.fc48eb4e3d946c1e9a49482512b573c3@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | ErrorMessages, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: adamgundry => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:24:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:24:06 -0000 Subject: [GHC] #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position In-Reply-To: <050.fd4ffb113813480ae17d2da8461f3f40@haskell.org> References: <050.fd4ffb113813480ae17d2da8461f3f40@haskell.org> Message-ID: <065.15b5f14e3ef24ba6a422a8f27a195d7c@haskell.org> #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5462, #7346, | Differential Rev(s): Phab:D2961 #12423 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"639e702b6129f501c539b158b982ed8489e3d09c/ghc" 639e702/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="639e702b6129f501c539b158b982ed8489e3d09c" Refactor DeriveAnyClass's instance context inference Summary: Currently, `DeriveAnyClass` has two glaring flaws: * It only works on classes whose argument is of kind `*` or `* -> *` (#9821). * The way it infers constraints makes no sense. It basically co-opts the algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly constrained instances, which in extreme cases can lead to legitimate things failing to typecheck (#12594). Or even worse, it can trigger GHC panics (#12144 and #12423). This completely reworks the way `DeriveAnyClass` infers constraints to fix these two issues. It now uses the type signatures of the derived class's methods to infer constraints (and to simplify them). A high-level description of how this works is included in the GHC users' guide, and more technical notes on what is going on can be found as comments (and a Note) in `TcDerivInfer`. Fixes #9821, #12144, #12423, #12594. Test Plan: ./validate Reviewers: dfeuer, goldfire, simonpj, austin, bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2961 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:24:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:24:06 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes In-Reply-To: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> References: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> Message-ID: <059.ee6cb9535b95c810b47524d8dff116ed@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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): Phab:D2961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"639e702b6129f501c539b158b982ed8489e3d09c/ghc" 639e702/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="639e702b6129f501c539b158b982ed8489e3d09c" Refactor DeriveAnyClass's instance context inference Summary: Currently, `DeriveAnyClass` has two glaring flaws: * It only works on classes whose argument is of kind `*` or `* -> *` (#9821). * The way it infers constraints makes no sense. It basically co-opts the algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly constrained instances, which in extreme cases can lead to legitimate things failing to typecheck (#12594). Or even worse, it can trigger GHC panics (#12144 and #12423). This completely reworks the way `DeriveAnyClass` infers constraints to fix these two issues. It now uses the type signatures of the derived class's methods to infer constraints (and to simplify them). A high-level description of how this works is included in the GHC users' guide, and more technical notes on what is going on can be found as comments (and a Note) in `TcDerivInfer`. Fixes #9821, #12144, #12423, #12594. Test Plan: ./validate Reviewers: dfeuer, goldfire, simonpj, austin, bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2961 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:24:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:24:06 -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.5b5743fa7ae3d0ec3153ad714b12df53@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"639e702b6129f501c539b158b982ed8489e3d09c/ghc" 639e702/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="639e702b6129f501c539b158b982ed8489e3d09c" Refactor DeriveAnyClass's instance context inference Summary: Currently, `DeriveAnyClass` has two glaring flaws: * It only works on classes whose argument is of kind `*` or `* -> *` (#9821). * The way it infers constraints makes no sense. It basically co-opts the algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly constrained instances, which in extreme cases can lead to legitimate things failing to typecheck (#12594). Or even worse, it can trigger GHC panics (#12144 and #12423). This completely reworks the way `DeriveAnyClass` infers constraints to fix these two issues. It now uses the type signatures of the derived class's methods to infer constraints (and to simplify them). A high-level description of how this works is included in the GHC users' guide, and more technical notes on what is going on can be found as comments (and a Note) in `TcDerivInfer`. Fixes #9821, #12144, #12423, #12594. Test Plan: ./validate Reviewers: dfeuer, goldfire, simonpj, austin, bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2961 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:24:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:24:06 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.650e836f8a7c89bcc5312e3a6ae05346@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12144 | Differential Rev(s): Phab:D2961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"639e702b6129f501c539b158b982ed8489e3d09c/ghc" 639e702/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="639e702b6129f501c539b158b982ed8489e3d09c" Refactor DeriveAnyClass's instance context inference Summary: Currently, `DeriveAnyClass` has two glaring flaws: * It only works on classes whose argument is of kind `*` or `* -> *` (#9821). * The way it infers constraints makes no sense. It basically co-opts the algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly constrained instances, which in extreme cases can lead to legitimate things failing to typecheck (#12594). Or even worse, it can trigger GHC panics (#12144 and #12423). This completely reworks the way `DeriveAnyClass` infers constraints to fix these two issues. It now uses the type signatures of the derived class's methods to infer constraints (and to simplify them). A high-level description of how this works is included in the GHC users' guide, and more technical notes on what is going on can be found as comments (and a Note) in `TcDerivInfer`. Fixes #9821, #12144, #12423, #12594. Test Plan: ./validate Reviewers: dfeuer, goldfire, simonpj, austin, bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2961 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:24:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:24:32 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.d5043037a38f2f05db80ae84075baa27@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): > We'd add the hash of mycppdstring to the .hi file. I follow this far. Now that the hash is in the .hi file, how does GHC know to recompile `A.hs` the next time `header.h` changes? Making a new ticket sounds good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:25:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:25:23 -0000 Subject: [GHC] #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position In-Reply-To: <050.fd4ffb113813480ae17d2da8461f3f40@haskell.org> References: <050.fd4ffb113813480ae17d2da8461f3f40@haskell.org> Message-ID: <065.da28f944b82ab100e82d4444d144c718@haskell.org> #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | tests/deriving/should_compile/T12144_1, | tests/deriving/should_compile/T12144_2 Blocked By: | Blocking: Related Tickets: #5462, #7346, | Differential Rev(s): Phab:D2961 #12423 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => tests/deriving/should_compile/T12144_1, tests/deriving/should_compile/T12144_2 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:26:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:26:25 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes In-Reply-To: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> References: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> Message-ID: <059.11467c374f7858cbc4a0a217d8c66aec@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/deriving/should_compile/T12594 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => tests/deriving/should_compile/T12594 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:27:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:27:10 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.4d8d53a6bb415c8615e3240d56ea7e58@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 see what's going on here. `tcRepSplitTyConApp_maybe` rightly needs to know the `RuntimeRep` of the argument type `([] |> <*>_N ->_N Sym {alzj}) a_alzd`. This `RuntimeRep` is buried in the from-type of the coercion hole `{alzj}`. We can see in the trace that `{alzj}` has from-type `k_agxC`. Except this has already been filled in with `*`. So the problem is that we haven't zonked yet -- and that's it. `can_eq_nc'` works over non-flat (that is, unzonked) types and also over flat (zonked) types. See `Note [Canonicalising equalities]` immediately above. Your decomposition will work on the zonked types. So returning `Nothing`, as you propose, works, as it forces `can_eq_nc'` to zonk and then try again, succeeding. Is `tcRepSplitTyConApp_maybe` used anywhere else? If so, returning `Nothing` in this case may be wrong.... except that returning `Nothing` in this case makes `tcRepSplitTyConApp_maybe` strictly more well-defined, so I suppose nothing can actually go wrong with this change. A detailed `Note` about the choice for `tcRepSplitTyConApp_maybe` not to panic is called for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:27:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:27:15 -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.7ba55d33c7ef50706a9aeb1cc2d10892@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 8.2.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: Related Tickets: #5462, #9968, | Differential Rev(s): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:27:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:27:51 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.7eea9d039cbb1cc4461dfbc162c16ae2@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | tests/deriving/should_compile/T12423 Blocked By: | Blocking: Related Tickets: #12144 | Differential Rev(s): Phab:D2961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => tests/deriving/should_compile/T12423 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:41:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:41:42 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.9acd3459d915d3a4aed0e15d7f25b60a@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 bgamari): goldfire, my previous statement claiming that there were only two callsites of `tcRepSplitTyConApp_maybe` was actually blatantly wrong. I neglected to consider the callsite in `tcSplitTyConApp_maybe`, which itself has dozens of sites. It seems like we really will need to have two variants of `tcRepSplitTyConApp_maybe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 21:47:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 21:47:54 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" Message-ID: <044.77633c3b8790ee4127144b398901f764@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Building current git head in the "BuildFlavour = perf-llvm", the build fails with: {{{ "inplace/bin/ghc-stage1" -o iserv/stage2_p/build/tmp/ghc-iserv-prof -hisuf \ p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O -H64m -fllvm -Wall \ -Werror -hide-all-packages -i -iiserv/src -iiserv/stage2_p/build \ -Iiserv/stage2_p/build -iiserv/stage2_p/build/iserv/autogen \ -Iiserv/stage2_p/build/iserv/autogen \ -optP-include -optPiserv/stage2_p/build/iserv/autogen/cabal_macros.h \ -package-id array-0.5.1.2 -package-id base-4.10.0.0 \ -package-id binary-0.8.4.1 -package-id bytestring-0.10.8.2 \ -package-id containers-0.5.7.1 -package-id deepseq-1.4.3.0 \ -package-id ghci-8.1 -package-id unix-2.7.2.1 -XHaskell2010 \ -threaded -optl-Wl,--export-dynamic -no-hs-main -no-user-package-db \ -rtsopts -Wnoncanonical-monad-instances -odir iserv/stage2_p/build \ -hidir iserv/stage2_p/build -stubdir iserv/stage2_p/build \ -static -prof -eventlog -O -H64m -fllvm -Wall -Werror -hide-all- packages \ -i -iiserv/src -iiserv/stage2_p/build \ -Iiserv/stage2_p/build -iiserv/stage2_p/build/iserv/autogen \ -Iiserv/stage2_p/build/iserv/autogen -optP-include \ -optPiserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id \ array-0.5.1.2 -package-id base-4.10.0.0 -package-id binary-0.8.4.1 \ -package-id bytestring-0.10.8.2 -package-id containers-0.5.7.1 \ -package-id deepseq-1.4.3.0 -package-id ghci-8.1 -package-id unix-2.7.2.1 \ -XHaskell2010 -threaded -optl-Wl,--export-dynamic -no-hs-main \ -no-user-package-db -rtsopts -Wnoncanonical-monad-instances \ iserv/stage2_p/build/Main.p_o iserv/stage2_p/build/GHCi/Utils.p_o \ iserv/stage2_p/build/cbits/iservmain.p_o Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: iserv/stage2_p/build/tmp/ghc-iserv-prof: Too many sections: 123418 (>= 65280) /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 22:00:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 22:00:30 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.d0878b3be994e068a4cb0faa6aa218e1@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:17 facundo.dominguez]: > I follow this far. Now that the hash is in the .hi file, how does GHC know to recompile `A.hs` the next time `header.h` changes? Ah, now I get what you're thinking about. No, cannot notice when it has to recompile A.hs when includes change; it would have to be the CPP to notice that (or ask the CPP what files it read, or run the CPP unconditionally). I was suggesting (but you're right, I didn't actually state it) that *when* we recompile A.hs, and notice `mystring` is unchanged (which would usually result in further compilation being avoided), we can invalidate *downstream* modules of `A.hs` based on the includes, even when the unexpanded argument `mystring` of `addModCStub` doesn't change. Sorry for the confusion. The value this would add is that you can touch (or save the buffer) of the module that contains the Haskell string to force a proper non-avoided build when (you know that) includes changed, as opposed to e.g. having to stack/cabal clean the entire project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 22:01:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 22:01:06 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.48ec15fb7415fdeac32956c51fd14db8@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:17 facundo.dominguez]: > Making a new ticket sounds good. Will do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 22:57:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 22:57:04 -0000 Subject: [GHC] #13266: Source locations from signature merging/matching are bad Message-ID: <045.df52d9521d868f6a0b0e85cc06acc041@haskell.org> #13266: Source locations from signature merging/matching are bad -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example output: {{{ /tmp/ghc3555_0/ghc_7.hscpp:1:1: error: No instance for (GHC.Enum.Enum t) arising when attempting to show that instance [safe] MonadHold t (PushM t) -- Defined in ‘z-reflex-z-common-0.5.0:Reflex.NewPure’ is provided by ‘z-reflex-z-common-0.5.0:Reflex.NewPure’ Possible fix: add (GHC.Enum.Enum t) to the context of the instance declaration | 1 | # 1 "indef/Reflex/Sig.hsig" }}} Unfortunately, this is not so easy to fix. Ordinarily, type errors occur while we are checking the source file in question, so we have plenty of SrcSpans from the parsed syntax tree to attach error to good source locations. However, a signature merge works differently: in general, we will have some interface files from our dependencies which we would like to merge together. If there is an incompatibility, there is NO local source declaration that we can get a SrcSpan for. So, what should we report in this case? One possibility is that we want to report the location of the source file *that produced the interface file.* But that would involve saving file paths in interface files, which seems quite distasteful to me, especially since the source location might be in a temporary directory, in which case you just broke determinism. So... I am not sure what to do here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 23:01:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 23:01:15 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.b1b4d9e01494af35bde72519fe7baf66@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): When GHC takes longer to compile the same file, it's sometime because it's generated bigger code. What does `-dshow-passes` show `ghc-before` and `ghc-after` compiling the same `DynFlags.hs`? `DynFlags` is a jolly big file. Are there smaller modules that show a big compile-time difference. `nofib-analyse` shows some per-module info I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 23:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 23:13:50 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.a84f509564ba932e02d2b09ecb334f0c@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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 simonpj): > Then "Tracking instance providers" needs to include this case as well Yes, good point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 10 23:24:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Feb 2017 23:24:24 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.9c717ca8857409887901214ad9160f77@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good data -- but * The terms seem to get bigger by 25% and the types/coercions by up to 50%. That does not account for a ''quadrupling'' of memory usage, as reported in the Description. I wonder if there is a space leak, which is beoming more obvious with this program? Worth taking a space profile? * I doubt that messinng around with default-method generation is going to help much. After all, the user might write the source code as in the tweaked version. What we should focus on is what causes the program size to increase so dramatically. Is it just the usual nested-tuple thing (which I still do now know how to fix), or is there more afoot? Maybe take a small example (one small type, one default method) and compare before and after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 00:11:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 00:11:04 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.a47000bcaf054a2220d8bd9a91af0bd3@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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): Maybe, but not necessarily. After all, the change we're proposing replaces a panic with a `Nothing`. In theory, no code (except the case we've identified in `can_eq_nc'`) should evaluate to the panic, so changing behavior there should have no effect beyond `can_eq_nc'`. However, practice does not always equate to theory, and this choice might change a helpful panic into very obscure behavior. So if the function ''is'' widely used, then I learn more toward the new-ADT approach: define something like {{{#!hs data SplitResult a b = Split a b | NotSplittable | NoRuntimeRep }}} where `NotSplittable` means that the type is a `FunTy` that would ordinarily be splittable, but retrieving the `RuntimeRep` failed. This failure should happen only when a) something is ill-kinded, or b) something needs a good zonk. This new ADT could be used in both `splitTyConApp` and `splitAppTy`. Or here's another approach: you're calling `tcRepSplitTyConApp_maybe`. Note the `tc`. How would we fare if this function were put into the `TcM` monad? Then, if the `RuntimeRep` were unavailable, we could zonk on the fly and succeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 00:19:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 00:19:22 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.7b4c920f99903f3e8ae7aab9949c90b3@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 have a terrible idea. Consider a unification variable (`MetaTv`) `alpha`. After `alpha` is filled in, say with `Int`, GHC should consider `alpha` and `Int` to be the same in all contexts. To achieve this, GHC must be very careful to zonk in just the right places. What if, instead, we use `unsafePerformIO` to zonk on the fly, whenever `coreView` is used? `coreView` looks through type synonyms, so it is currently put wherever we need to know about the "real" type -- in equality checks, splitting, etc. These places seem precisely the places where zonking is important. So we teach `coreView` how to zonk! Or, perhaps, we resurrect `tcView` (which was removed because it was just the same as `coreView`) so that this zonk-on-the-fly behavior happens only in the typechecker. Now, this idea (because it requires `unsafePerformIO`) goes against my grain. But what's actually wrong with it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 00:45:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 00:45:39 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it reduces away In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.cd210be010ececb78b988c5f1a364437@haskell.org> #13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This has been proposed before (though I can't find where), and I find the idea quite distasteful. Consider what this would mean at the term level: {{{ f :: Bool -> Int f (not True) = 5 f True = 6 }}} Parsing challenges aside, there's nothing at all wrong with the above declaration. But do we really want programmers to be able to do this? It's the same at the type level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 01:00:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 01:00:24 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.361e56f472102572b68607c901e1d060@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Sorry for not piping up sooner, but this change would be unsound. Consider this accepted program: {{{ data T a type role T nominal foo :: Coercible (T a) (T b) => a -> b foo x = x }}} You can see that, if `T` were abstract, instantiating `T` with a concrete datatype that had a phantom role would be Wrong. While there is a sub- roling relationship, it does not induce a sub-typing relationship like the one you seek. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 02:22:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 02:22:57 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.ec5f558ff8a27544903622a610df9f8c@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Blah, that's terrible. I'm trying to think how to solve this problem, because role mismatches in Backpack signatures are actually a problem in practice, that can't be easily worked around (speaking from experience Backpack'ing the reflex library). Let's leave aside hs-boot for now, where I think the current design works reasonably well. Here is my proposal: let's introduce a new "abstract" role which is a blend of the phantom and nominal roles: * Like phantom roles, we want `a ~A b` (where A is the abstract role) to hold for all choices a and b. Then, because the Co_Nth rule says that if `H a ~R H b`, then `a ~ρ b` (where ρ is the role of the first type parameter of H), when H's role is abstract, we learn nothing about a and b. This is sufficient to cause your example to fail to typecheck. * Like nominal roles, we should only have `H a ~R H b` if `a ~N b`; we would adjust the Co_TyConApp rule to always require nominal equality whenever we are at an abstract role type parameter. Since there are no rules where you can use `a ~A b` to derive another form of equality (in particular, we modified `Co_TyConApp` to require nominal equality), the existing safety proof should go through without modification. How does this sound? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 02:26:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 02:26:54 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it reduces away In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.e0100afd7e6cfcbcc9850a3a0693fdfd@haskell.org> #13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): By analogy, though, `TypeSynonymInstances` are also distasteful, because it's effectively letting you write `myfalse = False; f myfalse = 5` (well, that doesn't actually do what you want in Haskell today :o) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 04:04:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 04:04:01 -0000 Subject: [GHC] #13267: Constraint synonym instances Message-ID: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- Something funny happens when you try to declare an instance of a constraint synonym: {{{ {-# LANGUAGE ConstraintKinds #-} module F where type ShowF a = Show (a -> Bool) instance ShowF Int where show _ = "Fun" }}} I get: {{{ F.hs:8:5: error: ‘show’ is not a (visible) method of class ‘ShowF’ | 8 | show _ = "Fun" | ^^^^ }}} OK, but it gets weirder. Look at: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances #-} module F where type ShowF a = (Show (a -> Bool)) instance ShowF Int where }}} This is accepted (with a complaint that `show` is not implemented.) It gets even more awful: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} module F where type ShowF a = (Show Bool, Show Int) instance ShowF Int where }}} This is awful: GHC treats `Show Bool` and `Show Int` as if they were constraints, and then emits the following DFun: {{{ df9d1b4635f2a752f29ff327ab66d1cb $f(%,%)ShowShow :: (Show Bool, Show Int) DFunId {- Strictness: m, Inline: CONLIKE, Unfolding: DFun: @ a @ b. @ (Show Bool) @ (Show Int) $fShowBool $fShowInt -} }}} I don't even know what this is supposed to mean. OK, so what should we do? I think there are a few possibilities: 1. Completely outlaw instance declarations on constraint synonyms. 2. Allow instance declarations on constraint synonyms, but only if after desugaring the synonym, you end up with a single class head. I would find this useful in a few cases, for example, if you are writing `instance MonadSample (Impl t) MyMonad`, if you had `type MonadSample2 t a = MonadSample (Impl t) a` you might prefer writing `instance MonadSample t MyMonad` instead 3. Figure out what instance declarations with multiple class heads, and proceed accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 04:04:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 04:04:53 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.d39e16dcd7b7d08a5cbb5f5c6fc99657@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -73,2 +73,2 @@ - 3. Figure out what instance declarations with multiple class heads, and - proceed accordingly. + 3. Figure out what to do with instance declarations with multiple class + heads, and proceed accordingly. New description: Something funny happens when you try to declare an instance of a constraint synonym: {{{ {-# LANGUAGE ConstraintKinds #-} module F where type ShowF a = Show (a -> Bool) instance ShowF Int where show _ = "Fun" }}} I get: {{{ F.hs:8:5: error: ‘show’ is not a (visible) method of class ‘ShowF’ | 8 | show _ = "Fun" | ^^^^ }}} OK, but it gets weirder. Look at: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances #-} module F where type ShowF a = (Show (a -> Bool)) instance ShowF Int where }}} This is accepted (with a complaint that `show` is not implemented.) It gets even more awful: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} module F where type ShowF a = (Show Bool, Show Int) instance ShowF Int where }}} This is awful: GHC treats `Show Bool` and `Show Int` as if they were constraints, and then emits the following DFun: {{{ df9d1b4635f2a752f29ff327ab66d1cb $f(%,%)ShowShow :: (Show Bool, Show Int) DFunId {- Strictness: m, Inline: CONLIKE, Unfolding: DFun: @ a @ b. @ (Show Bool) @ (Show Int) $fShowBool $fShowInt -} }}} I don't even know what this is supposed to mean. OK, so what should we do? I think there are a few possibilities: 1. Completely outlaw instance declarations on constraint synonyms. 2. Allow instance declarations on constraint synonyms, but only if after desugaring the synonym, you end up with a single class head. I would find this useful in a few cases, for example, if you are writing `instance MonadSample (Impl t) MyMonad`, if you had `type MonadSample2 t a = MonadSample (Impl t) a` you might prefer writing `instance MonadSample t MyMonad` instead 3. Figure out what to do with instance declarations with multiple class heads, and proceed accordingly. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 04:05:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 04:05:18 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.6649af532442df9e532aa6f099f8ea66@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -70,1 +70,1 @@ - MonadSample (Impl t) a` you might prefer writing `instance MonadSample t + MonadSample (Impl t) a` you might prefer writing `instance MonadSample2 t New description: Something funny happens when you try to declare an instance of a constraint synonym: {{{ {-# LANGUAGE ConstraintKinds #-} module F where type ShowF a = Show (a -> Bool) instance ShowF Int where show _ = "Fun" }}} I get: {{{ F.hs:8:5: error: ‘show’ is not a (visible) method of class ‘ShowF’ | 8 | show _ = "Fun" | ^^^^ }}} OK, but it gets weirder. Look at: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances #-} module F where type ShowF a = (Show (a -> Bool)) instance ShowF Int where }}} This is accepted (with a complaint that `show` is not implemented.) It gets even more awful: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} module F where type ShowF a = (Show Bool, Show Int) instance ShowF Int where }}} This is awful: GHC treats `Show Bool` and `Show Int` as if they were constraints, and then emits the following DFun: {{{ df9d1b4635f2a752f29ff327ab66d1cb $f(%,%)ShowShow :: (Show Bool, Show Int) DFunId {- Strictness: m, Inline: CONLIKE, Unfolding: DFun: @ a @ b. @ (Show Bool) @ (Show Int) $fShowBool $fShowInt -} }}} I don't even know what this is supposed to mean. OK, so what should we do? I think there are a few possibilities: 1. Completely outlaw instance declarations on constraint synonyms. 2. Allow instance declarations on constraint synonyms, but only if after desugaring the synonym, you end up with a single class head. I would find this useful in a few cases, for example, if you are writing `instance MonadSample (Impl t) MyMonad`, if you had `type MonadSample2 t a = MonadSample (Impl t) a` you might prefer writing `instance MonadSample2 t MyMonad` instead 3. Figure out what to do with instance declarations with multiple class heads, and proceed accordingly. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 05:16:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 05:16:08 -0000 Subject: [GHC] #13268: Backpack doesn't work with Template Haskell, even when it should Message-ID: <045.cd14580b3e7c600311b01bfb065b9b08@haskell.org> #13268: Backpack doesn't work with Template Haskell, even when it should -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Obviously, we can't run Template Haskell from an indefinite package when we are (solely) typechecking the indefinite package itself. But in principle, Template Haskell code from other packages should be fair game. Alas, this not the case, because GHC attempts to dynamic link in libraries for ALL dependencies, including the ones we don't have code for. Quick fix should be to not link those in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 05:44:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 05:44:18 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.4706534ff5bf6aa02c233769a4df542d@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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 erikd): * failure: None/Unknown => Building GHC failed * version: 8.0.1 => 8.1 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 09:35:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 09:35:38 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.b1470dff618490f9c3ea0d4ebd292bc7@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by sgschlesinger): Yes, here is the relevant session: {{{ samuel at computer:~/Documents/lower/Data$ ghc Unbox.hs -XMagicHash -XDataKinds -XTypeInType -XTypeFamilies [1 of 1] Compiling Data.Unbox ( Unbox.hs, Unbox.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): kindPrimRep.go Rep Int 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 Feb 11 09:37:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 09:37:55 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.5243d4eb9c2649fd1a61654f64e1e8e3@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bollu Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollu): Why does the `Census` type `ssize_t` for `void_total`, `drag_total`, etc? wouldn't `size_t` be more appropriate, as they don't seem to be using the _signed_ property of `ssize_t`? The piece of code that causes the warning is {{{ fprintf(hp_file, "LAG\t%lu\n", (unsigned long)(census->not_used - census->void_total) * sizeof(W_)); }}} The `sizeof(W_) :: size_t` and `census->not_used :: ssize_t`. The solution that I'm proposing is to cast the `ssize_t` to a `size_t` and then change the format specifier to `%zu` as discussed on StackOverflow: [http://stackoverflow.com/questions/2125845/platform-independent-size-t -format-specifiers-in-c] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 09:41:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 09:41:28 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.d67c3bd652eca250ce5e09c5abc74a1b@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families ----------------------------------+---------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: pprIfaceCo Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by sgschlesinger): Behaviors to note: if I set "box = undefined", the code will compile but still have type errors when run with -dcore-lint, whereas if I set "unbox = undefined" the message is still the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 09:59:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 09:59:19 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.2fcfd0679a3d0ce52af84b9271a79364@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:21 simonpj]: > I strongly agree that we should write down the invariants for ticks So just to write down what we discussed the other day: * I believe there are (or were) no invariants on where ticks can appear in Core. However, there's an invariant that `(#,#)` must be directly applied to its type arguments, with no intervening ticks. (maybe it's more general than this?). Core Lint should really check this invariant. * We think that this invariant is satisfied by the desugarer but gets violated when the simplifier moves ticks inside type applications (https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreUtils.hs;639e702b6129f501c539b158b982ed8489e3d09c$342-344). We don't know if there are other places that might violate the invariant. * I (@simonmar) was worried that if we just stop doing this we might lose other beneficial transformations. @bgamari is going to try it and check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 10:12:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 10:12:06 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.d7f7e1419efeb998fa84292841b470d9@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 simonmar): smaller example: {{{ data A = forall a. A a st :: IO () st = do A _ <- pure (A True) x <- return 1 pure () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 10:21:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 10:21:50 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.f71528e5ca29b823dd918424c3f53d35@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bollu Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I actually question the use of `ssize_t` at all for these values. I think the calculations violate the expected value ranges of `ssize_t` namely with {{{ censuses[t].void_total += size; censuses[era].void_total -= size; }}} So I think the types in `_counter` are wrong and have the potential to do an unsigned underflow as `ssize_t` is only guaranteed to be able to store values between `[-1, {SSIZE_MAX}]`[1] [1]http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 10:35:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 10:35:22 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) In-Reply-To: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> References: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> Message-ID: <062.0a9d1a5b2d234b81d6a6089159c02cba@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining 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 phadej): * Attachment "RegBigger2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 10:39:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 10:39:02 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) In-Reply-To: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> References: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> Message-ID: <062.3f5c63aec09c95f951b99a6aeb28474f@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining 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 phadej): The code in RegBigger looks like Yesod code in trac:13253, but here we run in `IO`, not `MForm = RWST`. I checked all yesod-forms, back to http://hackage.haskell.org/package/yesod-form-0.2.0.1 released in *2011*, the `MForm` is `RWST` all the way down. I'd close this ticket (there is trac:13253), as there is no way to reproduce using `RegBigger.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 10:57:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 10:57:18 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.35bc6c17b33d572497cfca25d3cba42c@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 simonmar): @simonpj I've investigated this and run into something I don't understand, can you help? When we typecheck the above program without `ApplicativeDo` we get {{{ AbsBindsSig [] [] {Exported type: st :: IO () [LclId] Bind: st_aNk = do A{a_aNN EvBinds{[W] $dMonad_aNP = $dMonad_aNw [W] $dMonad_aNU = $dMonad_aNw [W] $dMonad_aZe = $dMonad_aNw [W] $dNum_aZc = GHC.Num.$fNumInteger @[] []}} _ <- pure @ IO $dApplicative_aNK @ A (A @ Bool True) x_aCp <- return @ IO $dMonad_aNU @ Integer 1 return @ IO $dMonad_aZe @ () () Evidence: EvBinds{}} }}} Note that `$dMonad_aNU`, used in the second statement, is bound by the `EvBinds` in the (existential) pattern in the first statement. ApplicativeDo isn't expecting there to be any dependencies between the two patterns, which is why it produces invalid Core. I don't understand why we're putting these dict bindings in the first pattern, they don't seem to relate to the existential type. I could just disable ApplicativeDo for existential patterns, but if that's necessary I'd like to understand why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 14:20:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 14:20:26 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.2323deaf2c78bd81dc5ba421fc69e4a7@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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 olsner): Which platform/OS was this on, and does it reproduce differently with/without `-fllvm`? If the platform binary format indeed doesn't support many sections we probably just need to tweak the conditions for the `SplitSections` default value. If it's happening on Linux or with ELF, it seems something less trivial is going on. The sections are supposed to get merged when linking an executable, so "support many sections" here is more about doing that merge in the default linker scripts than actually having binary format extensions for >64k sections. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 14:39:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 14:39:27 -0000 Subject: [GHC] #13269: Changes in includes of `addCStub` do not cause recompilation of downstream modules. Message-ID: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> #13269: Changes in includes of `addCStub` do not cause recompilation of downstream modules. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: inline-c | Operating System: Unknown/Multiple addCStub | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 13237 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Failing example: {{{ // header.h #include int f(int x) { printf("calling f(%d)\n",x); return x + 1; } }}} {{{ -- A.hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH.Syntax foreign import ccall f :: Int -> IO Int do addCStub "#include \"header.h\"" addDependentFile "header.h" return [] }}} {{{ -- B.hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH.Syntax import A do i <- runIO $ f 0 [d| fh = i |] main :: IO () main = print fh }}} {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling Main ( B.hs, B.o ) calling f(0) Linking B ... $ ./B 1 }}} Edit `header.h`: {{{ // header.h #include int f(int x) { printf("calling f(%d)\n",x); - return x + 1; + return x + 2; } }}} Recompiling we can see that `B.hs` is not rebuilt. And executing the program still shows the old result. {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [header.h changed] Linking B ... $ ./B 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 14:41:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 14:41:52 -0000 Subject: [GHC] #13269: Changes in includes of addCStub do not cause recompilation of downstream modules. (was: Changes in includes of `addCStub` do not cause recompilation of downstream modules.) In-Reply-To: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> References: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> Message-ID: <071.59dfad71e7ccf6e1baf026ed78dcb9fd@haskell.org> #13269: Changes in includes of addCStub do not cause recompilation of downstream modules. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c | addCStub Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 13237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -63,1 +63,1 @@ - Recompiling we can see that `B.hs` is not rebuilt. And executing the + Recompiling we can see that `B.hs` is not rebuilt and executing the New description: Failing example: {{{ // header.h #include int f(int x) { printf("calling f(%d)\n",x); return x + 1; } }}} {{{ -- A.hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH.Syntax foreign import ccall f :: Int -> IO Int do addCStub "#include \"header.h\"" addDependentFile "header.h" return [] }}} {{{ -- B.hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH.Syntax import A do i <- runIO $ f 0 [d| fh = i |] main :: IO () main = print fh }}} {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling Main ( B.hs, B.o ) calling f(0) Linking B ... $ ./B 1 }}} Edit `header.h`: {{{ // header.h #include int f(int x) { printf("calling f(%d)\n",x); - return x + 1; + return x + 2; } }}} Recompiling we can see that `B.hs` is not rebuilt and executing the program still shows the old result. {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [header.h changed] Linking B ... $ ./B 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 14:42:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 14:42:26 -0000 Subject: [GHC] #13269: Changes in includes of addCStub do not cause recompilation of downstream modules. In-Reply-To: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> References: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> Message-ID: <071.6993239bf8ce2e979a32ee392de64344@haskell.org> #13269: Changes in includes of addCStub do not cause recompilation of downstream modules. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c | addCStub Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * related: 13237 => #13237 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 14:56:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 14:56:28 -0000 Subject: [GHC] #12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup In-Reply-To: <047.dbe3294939f168d779839dd776514e40@haskell.org> References: <047.dbe3294939f168d779839dd776514e40@haskell.org> Message-ID: <062.36ceb1eefd2092a465cf5bd9e8e048b1@haskell.org> #12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup -------------------------------------+------------------------------------- Reporter: wozgonon | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by p1neapple): Another variant with this or a related bug: Importing a data constructor with named fields, but only the constructor, and destructing an object of that; with another constructor of the same name as one not imported in scope also crashes GHC, see code, try to compile Test.hs: {{{determinize}}} leads to a panic. {{{ -- File NonDeterministicAutomaton.hs: {-# LANGUAGE GADTs #-} module NonDeterministicAutomaton where import qualified Data.Set as DS data NonDeterministicAutomaton s a where NA :: (Monoid s) => { delta :: DeltaProto a s, acc :: DS.Set s, states :: DS.Set s } -> NonDeterministicAutomaton s a type DeltaProto a s = a -> s -> DS.Set s }}} {{{ -- file Test.hs: {-# LANGUAGE GADTs #-} module Test where import Prelude hiding (map, filter) import NonDeterministicAutomaton (NonDeterministicAutomaton(NA)) import Data.Set data DeterministicAutomaton s a where DA :: (Monoid s) => { delta :: DeltaProto a s, acc :: Set s, states :: Set s } -> DeterministicAutomaton s a type DeltaProto a s = a -> s -> s determinize :: (Eq s, Ord s) => NonDeterministicAutomaton s a -> DeterministicAutomaton (Set s) a determinize ( NA { delta = delta0, acc = acc0, states = naStates } ) = DA delta' acc' (singleton naStates) where acc' = filter (\x -> any (`elem` x) acc0) (singleton naStates) delta' a s = empty }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 15:23:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 15:23:01 -0000 Subject: [GHC] #13270: Make Core Lint faster Message-ID: <047.f4267b5b37a515c1dcc3b3bf7fcfc3c6@haskell.org> #13270: Make Core Lint faster -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Not using `-dcore-lint` makes the validate build 25% faster overall. See https://perf.haskell.org/ghc/#compare/639e702b6129f501c539b158b982ed8489e3d09c/0206750fcd3fe2299419a9020ec39fa557a866d0. We should at least profile it and check for anything egregiously inefficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 16:01:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 16:01:29 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.aad5517571a911d87a23a7da7b22af45@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ocharles): * cc: ocharles (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 16:48:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 16:48:39 -0000 Subject: [GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals In-Reply-To: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> References: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> Message-ID: <062.a0f2248abc47817e7dcb17d16dbe86b2@haskell.org> #13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 16:51:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 16:51:50 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.8386205c05c9215f6967e0579265fc76@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | 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): This is a duplicate of some other ticket. As I recall, the problem here is that the renamer wants to resolve the name `show` to a method of a particular class, at a point before we can normalize the type `ShowF`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 16:58:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 16:58:20 -0000 Subject: [GHC] #13271: GHC Panic With Injective Type Families Message-ID: <050.85e94bb0ec476229be5da928608f3194@haskell.org> #13271: GHC Panic With Injective Type Families ----------------------------------------+--------------------------------- Reporter: wayofthepie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following causes GHC to panic: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilyDependencies #-} module T where import GHC.TypeLits data T1 = T1 type T2 = TypeError (Text "You can't do that!") type family X i = r | r -> i where X 1 = T1 X 2 = T2 }}} {{{ $ ghc T.hs [1 of 1] Compiling T ( T.hs, T.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon T2 }}} This may be related to https://ghc.haskell.org/trac/ghc/ticket/11560. Without injectivity it gives the expected type error with the message "You can't do that!" {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} module T where import GHC.TypeLits data T1 = T1 type T2 = TypeError (Text "You can't do that!") type family X i where X 1 = T1 X 2 = T2 }}} {{{ $ ghc T.hs [1 of 1] Compiling T ( T.hs, T.o ) T.hs:9:1: error: • You can't do that • In the type synonym declaration for ‘T2’ }}} This isn't something anyone would intentionally write, as it could never type check with the type synonym T2 being a TypeError, but a panic is a panic so I said I'd raise it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 17:31:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 17:31:01 -0000 Subject: [GHC] #13237: Extend TH with addModCStub In-Reply-To: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> References: <056.582bfccd46a9ae25cbd9ae931b1a56a3@haskell.org> Message-ID: <071.2716231c7e135b05512f12f094c957e5@haskell.org> #13237: Extend TH with addModCStub -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: inline-c Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13269 | Differential Rev(s): Phab:D3106 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: patch => closed * resolution: => fixed * related: => #13269 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 18:08:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 18:08:38 -0000 Subject: [GHC] #13269: Changes in includes of addCStub do not cause recompilation of downstream modules. In-Reply-To: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> References: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> Message-ID: <071.3bc42d48232f8cab58ee104476bca8ed@haskell.org> #13269: Changes in includes of addCStub do not cause recompilation of downstream modules. -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c | addCStub addDependentFile Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * keywords: inline-c addCStub => inline-c addCStub addDependentFile @@ -3,1 +3,1 @@ - // header.h + // f.c @@ -23,2 +23,2 @@ - do addCStub "#include \"header.h\"" - addDependentFile "header.h" + do addCStub "#include \"f.c\"" + addDependentFile "f.c" @@ -52,1 +52,1 @@ - Edit `header.h`: + Edit `f.c`: @@ -54,1 +54,1 @@ - // header.h + // f.c @@ -67,1 +67,1 @@ - [1 of 2] Compiling A ( A.hs, A.o ) [header.h changed] + [1 of 2] Compiling A ( A.hs, A.o ) [f.c changed] New description: Failing example: {{{ // f.c #include int f(int x) { printf("calling f(%d)\n",x); return x + 1; } }}} {{{ -- A.hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH.Syntax foreign import ccall f :: Int -> IO Int do addCStub "#include \"f.c\"" addDependentFile "f.c" return [] }}} {{{ -- B.hs {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH.Syntax import A do i <- runIO $ f 0 [d| fh = i |] main :: IO () main = print fh }}} {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling Main ( B.hs, B.o ) calling f(0) Linking B ... $ ./B 1 }}} Edit `f.c`: {{{ // f.c #include int f(int x) { printf("calling f(%d)\n",x); - return x + 1; + return x + 2; } }}} Recompiling we can see that `B.hs` is not rebuilt and executing the program still shows the old result. {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [f.c changed] Linking B ... $ ./B 1 }}} -- Comment: Perhaps it could be fixed by adding a hash of the files pointed with `addDependendFile` to the module interface file. nh2 proposed in #13237 adding a hash of the cpp output over the string given to `addCStub`. Note though, that this behavior can be experienced without `addCStub` if one replaces `A.hs` with {{{ -- A.hs {-# LANGUAGE ForeignFunctionInterface #-} module A where import Language.Haskell.TH.Syntax foreign import ccall f :: Int -> IO Int }}} and builds with: {{{ $ ghc --make B.hs f.c -fPIC }}} I don't have ideas to fix this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 18:41:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 18:41:43 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.952eeaf46bc770674dbe79dca5a03ae1@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): There are two issues here. * Core Lint is expensive, and join points made it more expensive. For example `HsExpr` took twice as long to compile with `-O -dcore-lint` as with `-O`, before join points; and three times as long, after. I'm still waiting on some builds to finish, but I suspect most of the 13% build time regression is attributable to extra Core Lint checks added with join points. Just looking at the code, `markAllJoinsBad` looks somewhat expensive; and it is called on the right hand side of every binding, the body of every lambda, the scrutinee of every case, etc. This doesn't affect normal users, who won't use `-dcore-lint`. * Normal compiles (without `-dcore-lint`) are also slightly slower after join points. I'm working on getting better data on this and looking for outlier modules where the build time went up a lot. At Simon's suggestion, I looked at program sizes but they went up only a tiny bit on average (< 1%). The number of simplifier iterations also increased a tiny bit (< 1%). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 18:46:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 18:46:22 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) In-Reply-To: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> References: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> Message-ID: <062.a8d1390daab8d1a45c9a20852a055438@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining 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): I'd rather try to reconstruct the minimization that was used here, since it apparently didn't involve either transformers or INLINE pragmas. I asked the reporter of #10397 for the original test case, but no response yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 21:41:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 21:41:25 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.ec08e151112691ef342fb43b16407381@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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 erikd): This is on x86_64/linux. This is specifically about the `BuildFlavour = perf-llvm` so `-fllvm` is not optional. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 22:05:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 22:05:03 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable Message-ID: <050.046f36ed66c175f36546939641b2ee09@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- I was writing up an example to show off how `DeriveAnyClass` has improved since 639e702b6129f501c539b158b982ed8489e3d09c, and wouldn't you know it, the example doesn't actually compile anymore post- 639e702b6129f501c539b158b982ed8489e3d09c. Oopsie. {{{#!hs module TypeName where import GHC.Generics class TypeName a where typeName :: forall proxy. proxy a -> String default typeName :: forall proxy d f. (Generic a, Rep a ~ D1 d f, Datatype d) => proxy a -> String typeName _ = gtypeName $ from (undefined :: a) gtypeName :: Datatype d => D1 d f p -> String gtypeName = datatypeName data T a = MkT a deriving (Generic, TypeName) }}} This compiles before that commit. After it, however, it fails with the error: {{{ [1 of 1] Compiling TypeName ( Bug.hs, interpreted ) Bug.hs:23:22: error: • Couldn't match type ‘f’ with ‘C1 ('MetaCons "MkT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a))’ arising from the 'deriving' clause of a data type declaration ‘f’ is a rigid type variable bound by the deriving clause for ‘TypeName (T a)’ at Bug.hs:14:38 • When deriving the instance for (TypeName (T a)) | 23 | deriving (Generic, TypeName) | ^^^^^^^^ }}} I'm not sure why it's complaining only about `f` and not, say, `d`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 22:09:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 22:09:37 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel In-Reply-To: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> References: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> Message-ID: <060.27058f6d8ebfd73386a1b9f1ab28e1d6@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I implemented a simple web dashboard which shows when situations 1. and 2. are occurring. The question now is whether this should be hosted somewhere or if anyone other than me would use it. Red = 1 Orange = 2 The code is also not very pretty and I am not too keen to tidy it up so I might just manage this myself. https://usercontent.irccloud-cdn.com/file/IZlVhIjK/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 22:32:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 22:32:25 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.76c59a8ab4f261624abf5df4d053d06f@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): And it gets worse if you make a slight tweak to the original program by introducing an intermediary type variable: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module TypeName where import GHC.Generics class TypeName a where typeName :: proxy a -> String default typeName :: (Generic a, Rep a ~ gg, gg ~ D1 d f, Datatype d) => proxy a -> String typeName _ = gtypeName $ from (undefined :: a) gtypeName :: Datatype d => D1 d f p -> String gtypeName = datatypeName data T a = MkT a deriving (Generic, TypeName) }}} Then it sends the compiler (presumably the constraint solver) into an infinite loop! I'll attach the portion of `-ddump-tc-trace`'s output that appears to be looping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 22:32:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 22:32:59 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.d9ab9ab2f450096ea13e21ff34bd1716@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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 RyanGlScott): * Attachment "13272-ddump-tc-trace-loop.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 11 23:38:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Feb 2017 23:38:59 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.6e06170581bc424b8ffeeae8efbac291@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -7,0 +7,6 @@ + {-# LANGUAGE DefaultSignatures #-} + {-# LANGUAGE DeriveAnyClass #-} + {-# LANGUAGE DeriveGeneric #-} + {-# LANGUAGE FlexibleContexts #-} + {-# LANGUAGE ScopedTypeVariables #-} + {-# LANGUAGE TypeFamilies #-} New description: I was writing up an example to show off how `DeriveAnyClass` has improved since 639e702b6129f501c539b158b982ed8489e3d09c, and wouldn't you know it, the example doesn't actually compile anymore post- 639e702b6129f501c539b158b982ed8489e3d09c. Oopsie. {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module TypeName where import GHC.Generics class TypeName a where typeName :: forall proxy. proxy a -> String default typeName :: forall proxy d f. (Generic a, Rep a ~ D1 d f, Datatype d) => proxy a -> String typeName _ = gtypeName $ from (undefined :: a) gtypeName :: Datatype d => D1 d f p -> String gtypeName = datatypeName data T a = MkT a deriving (Generic, TypeName) }}} This compiles before that commit. After it, however, it fails with the error: {{{ [1 of 1] Compiling TypeName ( Bug.hs, interpreted ) Bug.hs:23:22: error: • Couldn't match type ‘f’ with ‘C1 ('MetaCons "MkT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a))’ arising from the 'deriving' clause of a data type declaration ‘f’ is a rigid type variable bound by the deriving clause for ‘TypeName (T a)’ at Bug.hs:14:38 • When deriving the instance for (TypeName (T a)) | 23 | deriving (Generic, TypeName) | ^^^^^^^^ }}} I'm not sure why it's complaining only about `f` and not, say, `d`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:08:31 -0000 Subject: [GHC] #13214: Orphan instances in Backpack signatures don't work In-Reply-To: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> References: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> Message-ID: <060.0df28817469eb4620f670e59e5df4f1b@haskell.org> #13214: Orphan instances in Backpack signatures don't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3095 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"26eaa7ecde288b9dc123f3c120e70b2cf18b4e4a/ghc" 26eaa7ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="26eaa7ecde288b9dc123f3c120e70b2cf18b4e4a" Fix #13214 by correctly setting up dep_orphs for signatures. Prior to this, I hadn't thought about orphan handling at all. This commit implements the semantics that if a signature (transitively) imports an orphan instance, that instance is considered in scope no matter what the implementing module is. (As it turns out, this is the semantics that falls out when orphans are recorded transitively.) This patch fixes a few bugs: 1. Put semantic modules in dep_orphs rather than identity modules. 2. Don't put the implementing module in dep_orphs when merging signatures (this is a silly bug that happened because we were reusing calculateAvails, which is designed for imports. It mostly works for signature merging, except this case.) 3. When renaming a signature, blast in the orphans of the implementing module inside Dependencies. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3095 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:08:31 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.f2e203c4be8806f444108c7fd0bdd7ad@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: #12780 | Differential Rev(s): Phab:D3105 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"07292e958cb0c08705d9a694f09d9621058b16e6/ghc" 07292e95/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07292e958cb0c08705d9a694f09d9621058b16e6" zonkCt tries to maintain the canonical form of a Ct. For example, - a CDictCan should stay a CDictCan; - a CTyEqCan should stay a CTyEqCan (if the LHS stays as a variable.). - a CHoleCan should stay a CHoleCan Why? For CDicteqCan see Trac #11525. Test Plan: Validate Reviewers: austin, adamgundry, simonpj, goldfire, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3105 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:08:31 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.f6a42df9105109c78922465e3ee96d54@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4e2e9b7324e253295613fe868a281e1801e05d10/ghc" 4e2e9b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4e2e9b7324e253295613fe868a281e1801e05d10" Fix: Default FD buffer size is not a power of 2 (#13245) Reviewers: simonmar, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3115 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:08:31 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.c0234baaa57c9c9edff3f73cf0354cf2@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Phab:D3117 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"805db96544111bd548c9a32488a9c97996cc2b49/ghc" 805db965/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="805db96544111bd548c9a32488a9c97996cc2b49" Fix: hPutBuf issues unnecessary empty write syscalls for large writes (#13246) Until now, any `hPutBuf` that wrote `>= the handle buffer size` would trigger an unnecessary `write("")` system call before the actual write system call. This is fixed by making sure that we never flush an empty handle buffer: Only flush `when (w > 0)`. Reviewers: simonmar, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3119 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:08:31 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.9828b73352db15ade5e6a4829fc3bca5@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.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:D1242 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a50082c115bed1891b2e5aac4a21462935f4f0d6/ghc" a50082c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a50082c115bed1891b2e5aac4a21462935f4f0d6" Apply SplitSections to all C compilations Previously this was added only to the RTS's C files (those are the bulk of it though), but there are C bits in ghc-prim, integer-gmp and base too. Followup for #8405, allows the large table of character properties in base to be stripped when not used. Test Plan: validate Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3121 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:29:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:29:02 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.d9e4b2228f2761f8e221e7ca27816694@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Phab:D3117 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.2.1 => 8.0.3 Comment: At the moment we don't have a compelling reason to release a 8.0.3 but I'll milestone it there regardless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:29:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:29:13 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.e18387f7b8a3f51bc15d0f08dca17d37@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3115 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:30:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:30:50 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.1982ff32a6cf09e34ca4d6df025186d6@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: #12780 | Differential Rev(s): Phab:D3105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: 8.2.1 => 8.0.3 Comment: If we do a 8.0.3 it would likely be worthwhile trying to backport this since it's a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 01:30:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 01:30:59 -0000 Subject: [GHC] #13214: Orphan instances in Backpack signatures don't work In-Reply-To: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> References: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> Message-ID: <060.0d04827ff7d9dbb77b765d02ed61450f@haskell.org> #13214: Orphan instances in Backpack signatures don't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3095 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 02:16:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 02:16:31 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.0caa8fb55f9143ef24cd228a4aeeaf17@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #11068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics * related: => #5642, #11068 Comment: After staring at this some more, I think I have a more solid grasp of what is going on here. I stared at the code pre-54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060 (which I will henceforth refer to as "8.0.1" for brevity), and noticed something interesting about the code which generates default method implementations for things that use `DefaultSignatures` (`GenericDM`): {{{#!hs tc_default sel_id (Just (dm_name, GenericDM {})) = do { meth_bind <- mkGenericDefMethBind clas inst_tys sel_id dm_name ; tcMethodBody clas tyvars dfun_ev_vars inst_tys dfun_ev_binds is_derived hs_sig_fn prags sel_id meth_bind inst_loc } }}} Compare this to the treatment for non-`DefaultSignatures`-using default method implementations (`VanillaDM`): {{{#!hs tc_default sel_id (Just (dm_name, VanillaDM)) -- A polymorphic default method = do { ... ; let dm_inline_prag = idInlinePragma dm_id rhs = HsWrap (mkWpEvVarApps [self_dict] <.> mkWpTyApps inst_tys) $ HsVar (noLoc dm_id) meth_bind = mkVarBind local_meth_id (L inst_loc rhs) meth_id1 = meth_id `setInlinePragma` dm_inline_prag -- Copy the inline pragma (if any) from the default -- method to this version. Note [INLINE and default methods] export = ABE { abe_wrap = idHsWrapper , abe_poly = meth_id1 , abe_mono = local_meth_id , abe_prags = mk_meth_spec_prags meth_id1 spec_inst_prags [] } bind = AbsBinds { abs_tvs = tyvars, abs_ev_vars = dfun_ev_vars , abs_exports = [export] , abs_ev_binds = [EvBinds (unitBag self_ev_bind)] , abs_binds = unitBag meth_bind } ; return (meth_id1, L inst_loc bind, Nothing) } }}} One crucial difference between the two is that in the latter `VanillaDM` case, it explicitly copies any user-supplied `INLINE` pragmas, whereas in the former `GenericDM` case, it does not! (I've perused the definition of `tcMethodBody` to make sure of this.) Now after 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060 (which I will refer to as "8.0.2" from here on out), the treatment of generic and non-generic default method implementations were unified, and split out into the `mkDefMethBind` function (source [http://git.haskell.org/ghc.git/blob/d3ea38ef0299e9330a105fa59dda38f9ec0712c4:/compiler/typecheck/TcInstDcls.hs#l1538 here]). It is quite similar to the treatment of `VanillaDM` before, and in particular, it also copies any user-supplied `INLINE` pragmas. What does this have to do with `store`? The code in `store` uses a design pattern that tends to result in huge amounts of memory consumption: it uses lots of `GHC.Generics` instances and marks pretty much everything with `INLINE`. Overly aggressive use of `GHC.Generics` has been known to lead to memory blowup before (see #5642 and #11068). The common patterns between those tickets are: 1. Defining "generic classes" with more than one method 2. Putting `INLINE` methods on all instances for `GHC.Generics` datatypes `store` does not exhibit the first issue, so I can state with reasonable certainty that this problem falls into the second camp. So why did this problem only arise in 8.0.2? In 8.0.1 and earlier, GHC would desugar `DefaultSignatures` method implementations like: {{{#!hs instance Store Foo where size = $gdm_size Foo $dStoreFoo }}} This //lacks// an `INLINE` pragma. But in 8.0.2, it's desugared as: {{{#!hs instance Store Foo where size = $gdm_size @Foo {-# INLINE size #-} }}} But `$gdm_size = genericSize`, and `genericSize` is the composition of tons of `INLINE`d `GHC.Generics` functionality. We know that `GHC.Generics` has a propensity for high memory usage, and adding this extra `INLINE` pragma is enough to make the difference between 1.6 GB and 5.17 GB of memory when compiling the insanely high number of `GHC.Generics`-based instances in `store`. This claim is backed up by comment:17, where explicitly implementing the instances and adding `INLINE` pragmas resulted in the same high memory usage in both 8.0.1 and 8.0.2. So in the end, this is really just another case of `GHC.Generics` of being (ab)used in a way that it doesn't handle well (at least, not at the moment). I didn't spend much time digging into the space profiles for these programs in 8.0.1 and 8.0.2, as both just stated that `SimplTopBinds` took the bulk of the time without going into more detail, which wasn't terribly helpful. But all is not lost for `store`, as this analysis reveals a workaround. If you remove just the right `INLINE` pragmas from `store`: {{{#!diff diff --git a/src/Data/Store/Impl.hs b/src/Data/Store/Impl.hs index 26ea82e..bbf62a5 100644 --- a/src/Data/Store/Impl.hs +++ b/src/Data/Store/Impl.hs @@ -64,15 +64,15 @@ class Store a where default size :: (Generic a, GStoreSize (Rep a)) => Size a size = genericSize - {-# INLINE size #-} + -- {-# INLINE size #-} default poke :: (Generic a, GStorePoke (Rep a)) => a -> Poke () poke = genericPoke - {-# INLINE poke #-} + -- {-# INLINE poke #-} default peek :: (Generic a , GStorePeek (Rep a)) => Peek a peek = genericPeek - {-# INLINE peek #-} + -- {-# INLINE peek #-} ------------------------------------------------------------------------ -- Utilities for encoding / decoding strict ByteStrings }}} Then I can confirm that compiling `store` with GHC 8.0.1 and 8.0.2 both result in about 1.7 GB of maximum memory residency. And given the [https://github.com/bos/aeson/pull/335#issuecomment-172730336 benchmark results for a similar patch] that I made for `aeson`, I don't think this would result in much of a difference in performance, if any. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 02:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 02:16:34 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.d06700ecab5ee56a725fcc3c011b63de@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -5,1 +5,1 @@ - extensions.html). There is one problem though. Lets consider following + extensions.html). There is one problem though. Let's consider following New description: Hello! The reason behind using `IncoherentInstances`is that we want GHC to commit to a specific instance even if after instantiation of some variables, other instance could be more specific (http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/type-class- extensions.html). There is one problem though. Let's consider following example (which could not make much sense, but shows the problem well): {{{#!haskell {-# OPTIONS_GHC -fno-warn-missing-methods #-} {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE IncoherentInstances #-} {-# LANGUAGE ScopedTypeVariables #-} module Main where import Data.Typeable -------------------------------------------------------------------------------- -- Type classes -------------------------------------------------------------------------------- class InferType a where inferType :: Proxy a -> Proxy a inferType = undefined -------------------------------------------------------------------------------- -- Proxy datatypes -------------------------------------------------------------------------------- data Id0 = Id0 deriving (Show, Typeable) data Id1 t1 = Id1 deriving (Show, Typeable) data Id2 t1 t2 = Id2 deriving (Show, Typeable) data Id3 t1 t2 t3 = Id3 deriving (Show, Typeable) data Id4 t1 t2 t3 t4 = Id4 deriving (Show, Typeable) data Id5 t1 t2 t3 t4 t5 = Id5 deriving (Show, Typeable) -------------------------------------------------------------------------------- -- Instances -------------------------------------------------------------------------------- instance InferType Int instance (InferType m, InferType a) => InferType (m a) instance (a~Id0) => InferType (a :: *) instance (a~Id1) => InferType (a :: * -> *) instance (a~Id2) => InferType (a :: * -> * -> *) -------------------------------------------------------------------------------- -- Tests -------------------------------------------------------------------------------- toProxy :: a -> Proxy a toProxy _ = Proxy --inferTypeBase :: a -> Proxy a inferTypeBase a = inferType $ toProxy a instance InferType Foo1 instance InferType Foo2 tm _ = 5 data Foo1 a = Foo1 a deriving (Show, Typeable) data Foo2 a b = Foo2 a b deriving (Show, Typeable) instance Monad Id1 -- dummy instances just for tests instance Num Id0 main = do print $ typeOf $ inferType $ toProxy $ (return (5)) print $ typeOf $ inferType $ toProxy $ (5) print $ typeOf $ inferType $ toProxy $ (Foo1 (return 5)) print $ typeOf $ inferType $ toProxy $ (Foo2 (return 5) (return 5)) print "hello" ---- OUTPUT: -- Proxy (Id1 Id0) -- Proxy Id0 -- Proxy (Foo1 (Id1 Id0)) -- Proxy (Foo2 (Id1 Id0) (Id1 Id0)) -- "hello" }}} The idea is very simple - replace all unknown type variables with known ones. It works great, but the problem appears with the function `inferTypeBase`. It should have type of `a -> Proxy a`, but GHC claims it has got `Id0 -> Proxy Id0`. It is of course caused by enabled `-XIncoherentInstances` flag, but I think GHC should be more liberal here. If it really cannot pick any instance (causing an error using only `OverlappingInstances`), the `IncoherentInstances` should allow it to pick matching one even if more specific could be available after instantianization. But If no error would occur while using `OverlappingInstances`, `IncoherentInstances` should not affect the way it resolves the instances. I think this would make `IncoherentInstances` much more useful than now. Maybe it would be good to just add some options to the flag? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 03:30:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 03:30:43 -0000 Subject: [GHC] Trac email verification for user: lukemaurer Message-ID: <20170212033043.5FD053A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: lukemaurer Verification Token: F1NzcGTk -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 08:51:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 08:51:31 -0000 Subject: [GHC] #13273: AttributeError: 'Environment' object has no attribute 'get_db_cnx' Message-ID: <044.9ce9b60c569e94c46e10c4708d397470@haskell.org> #13273: AttributeError: 'Environment' object has no attribute 'get_db_cnx' -------------------------------------+------------------------------------- Reporter: Siddharth | Owner: (none) Bhat | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- ==== How to Reproduce ==== While doing a POST operation on `/ticket/12636`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {u'__FORM_TOKEN': u'73aa35b2c757eee5d2b0ae62', u'action': u'leave', u'action_assign_reassign_owner': u'bollu', u'action_resolve_resolve_resolution': u'fixed', u'comment': u'I believe the guarantee at that chunk of code is that `void_total` of the era will be `>= 0`.\r\n\r\nI could add an asset at those sections of code if need be. If not, what is the correct type to be used here? I think `size_t` is reasonable as none of them are supposed to be negative in the first place.\r\n\r\n', u'field_architecture': u'Unknown/Multiple', u'field_blockedby': u'', u'field_blocking': u'', u'field_cc': u'simonmar', u'field_component': u'Runtime System', u'field_description': u'during compile I noticed\r\n\r\n{{{\r\nrts\\ProfHeap.c: In function \'dumpCensus\':\r\n\r\nrts\\ProfHeap.c:768:26: error:\r\n warning: format \'%lu\' expects argument of type \'long unsigned int\', but argument 3 has type \'long long unsigned int\' [-Wformat=]\r\n fprintf(hp_file, "VOID\\t%lu\\n",\r\n ^\r\n\r\nrts\\ProfHeap.c:770:26: error:\r\n warning: format \'%lu\' expects argument of type \'long unsigned int\', but argument 3 has type \'long long unsigned int\' [-Wformat=]\r\n fprintf(hp_file, "LAG\\t%lu\\n",\r\n ^\r\n\r\nrts\\ProfHeap.c:772:26: error:\r\n warning: format \'%lu\' expects argument of type \'long unsigned int\', but argument 3 has type \'long long unsigned int\' [-Wformat=]\r\n fprintf(hp_file, "USE\\t%lu\\n",\r\n ^\r\n\r\nrts\\ProfHeap.c:774:26: error:\r\n warning: format \'%lu\' expects argument of type \'long unsigned int\', but argument 3 has type \'long long unsigned int\' [-Wformat=]\r\n fprintf(hp_file, "INHERENT_USE\\t%lu\\n",\r\n ^\r\n\r\nrts\\ProfHeap.c:776:26: error:\r\n warning: format \'%lu\' expects argument of type \'long unsigned int\', but argument 3 has type \'long long unsigned int\' [-Wformat=]\r\n fprintf(hp_file, "DRAG\\t%lu\\n",\r\n ^\r\n}}}\r\n', u'field_differential': u'', u'field_failure': u'None/Unknown', u'field_keywords': u'newcomer', u'field_milestone': u'', u'field_os': u'Windows', u'field_priority': u'normal', u'field_related': u'', u'field_summary': u"ProfHeap's printf modifiers are incorrect", u'field_testcase': u'', u'field_type': u'bug', u'field_version': u'8.0.1', u'field_wikipage': u'', 'id': u'12636', u'replyto': u'', u'sfp_email': u'', u'sfph_mail': u'', u'start_time': u'1486808510359145', u'submit': u'Submit changes', u'view_time': u'1486808510359145'} }}} User agent: `#USER_AGENT#` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Interface Customization ==== ''Interface customization information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 613, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 253, in dispatch resp = chosen_handler.process_request(req) File "/usr/local/lib/python2.7/dist-packages/trac/ticket/web_ui.py", line 177, in process_request return self._process_ticket_request(req) File "/usr/local/lib/python2.7/dist-packages/trac/ticket/web_ui.py", line 661, in _process_ticket_request valid = self._validate_ticket(req, ticket, not valid) and valid File "/usr/local/lib/python2.7/dist-packages/trac/ticket/web_ui.py", line 1378, in _validate_ticket for field, message in manipulator.validate_ticket(req, ticket): File "build/bdist.linux-x86_64/egg/defaultcc/main.py", line 31, in validate_ticket comp_default_cc = DefaultCC(self.env, ticket['component']) File "build/bdist.linux-x86_64/egg/defaultcc/model.py", line 25, in __init__ db = self.env.get_db_cnx() AttributeError: 'Environment' object has no attribute 'get_db_cnx' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 13:13:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 13:13:30 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later In-Reply-To: <043.b25e91253b49ad08042d636adf423d59@haskell.org> References: <043.b25e91253b49ad08042d636adf423d59@haskell.org> Message-ID: <058.a5d8a98f1ad9988137acb69ec5e3e437@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: Ashish SHUKLA | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo): You can get around this by configuring GHC with `--disable-large-address- space` and rebuilding it. This turns off the large address space features to give the same behavior as versions of GHC before 8.0. It would also be interesting to test whether `#defined MAP_NO_RESERVE 0` at the top of `rts/posix/OSMem.c` and configuring with `--enable-large- address-space` results in a working compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 13:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 13:38:29 -0000 Subject: [GHC] #13269: Changes in foreign code used in TH do not trigger recompilation (was: Changes in includes of addCStub do not cause recompilation of downstream modules.) In-Reply-To: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> References: <056.8a057fa9e1c52a823b25f5605d749fd6@haskell.org> Message-ID: <071.8731296916a567207e9e14e075ec2a8c@haskell.org> #13269: Changes in foreign code used in TH do not trigger recompilation -------------------------------------+------------------------------------- Reporter: Facundo | Owner: (none) Domínguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: inline-c | addCStub addDependentFile Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 14:51:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 14:51:29 -0000 Subject: [GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes In-Reply-To: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> References: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> Message-ID: <066.26eb5a9a13332d2bd36daf9249ebf29b@haskell.org> #8635: GHC optimisation flag ignored when importing a local module with derived type classes -------------------------------------+------------------------------------- Reporter: Neil Mitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #9370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Ben Gamari: Old description: > Given Foo.hs and Bar.hs: > > {{{ > module Foo where > data Food = Food -- deriving Eq > > {-# OPTIONS_GHC -O2 -ddump-simpl #-} > module Bar where > import Foo > bar :: Int -> Bool > bar x = x == 72 > }}} > > If I run: > > {{{ > ghc --make Bar -fforce-recomp > }}} > > I get (snipped): > > {{{ > Bar.bar = > \ (x_afk :: GHC.Types.Int) -> > case x_afk of _ { GHC.Types.I# x1_alo -> > case x1_alo of _ { > __DEFAULT -> GHC.Types.False; > 72 -> GHC.Types.True > } > } > }}} > > `bar` now looks pretty well optimised. However, if I uncomment the > `deriving Eq` I get: > > {{{ > Bar.bar1 = GHC.Types.I# 72 > Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt > Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 > }}} > > Now `bar` looks like terrible code, using dictionaries, boxing etc. It > seems adding `deriving` in the imported and unused module makes it ignore > the optimisation level. New description: Given Foo.hs and Bar.hs: {{{#!hs module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 14:52:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 14:52:24 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.7c439aeccc1fc93ed7e2fbf38b073ceb@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Siddharth | Bhat Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3129 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3129 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 14:53:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 14:53:53 -0000 Subject: [GHC] #13274: GHC library is accumulating exported symbols at a very rapid rate. Message-ID: <044.ff2afcb5c79a83b2de9965cf9260888f@haskell.org> #13274: GHC library is accumulating exported symbols at a very rapid rate. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5987 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On `20160617` libHSghc had `49610` exported symbols. This was gotten by doing `nm -g $5 | sed -nr 's/^[a-z,A-Z,0-9]+\s([A-Z])\s(.+)$/\1 \2\n/p' | sed -r 's/^.+:.*$//g' | sed '/^\s*$/d' | sort | uniq -u` on all object files given to link `libHSghc`. After rebasing on newer commit `20161015` 4 months later it now has `124966` exported symbols. This is an explosive increase in symbol count of nearly 300%. On `20170208` this is now even higher `147927` which is another big increase. Unfortunately it's not easy for me to go back to the first build since my git has been pruned. But I do have the list for the latest jump. Should be investigated why. This rate will be problematic for #5987 as it means we'll keep adding DLLs. Currently with the current head it needs to split in 3 DLLs, and it's not far from a 4th. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 15:15:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 15:15:46 -0000 Subject: [GHC] #13274: GHC library is accumulating exported symbols at a very rapid rate. In-Reply-To: <044.ff2afcb5c79a83b2de9965cf9260888f@haskell.org> References: <044.ff2afcb5c79a83b2de9965cf9260888f@haskell.org> Message-ID: <059.462d129a24f16c4e4fa735591f7b06f4@haskell.org> #13274: GHC library is accumulating exported symbols at a very rapid rate. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #5987 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => wontfix * milestone: 8.4.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 15:45:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 15:45:31 -0000 Subject: [GHC] #13275: ghci ignores -fprint-explicit-runtime-reps Message-ID: <045.9c5f6f92d9ccfac27eb19f38ae2cdb47@haskell.org> #13275: ghci ignores -fprint-explicit-runtime-reps -------------------------------------+------------------------------------- Reporter: Konrad Gądek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: levity | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docs [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using.html #ghc-flag--fprint-explicit-runtime-reps here] mentions the following use- case: {{{ ghci> :t ($) ($) :: (a -> b) -> a -> b ghci> :set -fprint-explicit-runtime-reps ghci> :t ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b }}} However, I get this: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ Prelude> :set -fprint-explicit-runtime-reps Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ }}} I'm not sure if the docs are wrong or GHCi is erroneously ignoring the flag when using `:t`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 16:17:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 16:17:11 -0000 Subject: [GHC] Trac email verification for user: KellePurton2 Message-ID: <20170212161711.7D1DF3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: KellePurton2 Verification Token: CWs7ydsz -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 16:25:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 16:25:18 -0000 Subject: [GHC] Trac email verification for user: SherrylGayman9 Message-ID: <20170212162518.246343A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: SherrylGayman9 Verification Token: 3ZAICY_g -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 17:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 17:43:36 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.8dbc11c1a0a0ee65b1e6406363aac101@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Joachim | Breitner Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Joachim Breitner): * status: new => closed * resolution: => fixed Comment: Phab:D3089 has landed as changeset:a1980ecb5626ec85fc14fbd217e2d16c7d50a120. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 17:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 17:53:08 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable Message-ID: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: typeable | 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 the Typeable machinery introduce in the type-indexed Typeable rework (#11011) is fully capable of representing unboxed sums, we currently don't allow this since it would require that we generate an enormous number of bindings in `GHC.Types`. This is because we need to generate both `TyCon` and `KindRep` bindings for each type constructor and its promoted data constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 17:59:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 17:59:34 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.47b4005e2f00586c54f963b48f525d1a@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ben Gamari): * related: => #12276 Comment: The unboxed sum problem is discussed in #13276. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 18:00:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 18:00:09 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.afddfb9ebc8f38ca50eae80772fe98aa@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13261 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ben Gamari): * related: => #13261 Comment: One possible solution to this would be to move `TyCon` generation wholly or in part back to the solver, as discussed in #13261. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 18:56:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 18:56:31 -0000 Subject: [GHC] #13259: cross-endian GHC generates invalid .hi files In-Reply-To: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> References: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> Message-ID: <060.013b163b2e8b43d337f54c4d2282af7e@haskell.org> #13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 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): Phab:D3122 Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Was merged to -HEAD as changeset:d3ea38ef0299e9330a105fa59dda38f9ec0712c4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 18:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 18:56:59 -0000 Subject: [GHC] #13259: cross-endian GHC generates invalid .hi files In-Reply-To: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> References: <045.b2782ad05defc140ad349e0d9bb3025e@haskell.org> Message-ID: <060.4a29bf91f5dcd696aef43e417975aea7@haskell.org> #13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3122 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 19:35:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 19:35:58 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation In-Reply-To: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> References: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> Message-ID: <064.1c9b7867f1d7d940058d626b93351b7c@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template | haskell, recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lippling): I noticed that the bug only arises with `-O0`. With `-O2` the app compiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 19:41:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 19:41:54 -0000 Subject: [GHC] #13277: When type classes are redefined in GHCi bindings that use old instances are still accessible Message-ID: <044.c914dfe329327845e56ac7e6d4602a5b@haskell.org> #13277: When type classes are redefined in GHCi bindings that use old instances are still accessible -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found the following behavior surprising: {{{#!hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /tmp/ghci7261/ghci-script Prelude> class Foo a where { foo :: a -> Int } Prelude> instance Foo () where { foo _ = 1 } Prelude> f = foo () Prelude> class Foo a where { foo :: a -> IO () } Prelude> f 1 }}} `Foo` is redefined but `f` which uses a now illegal instance of `Foo` is still accessible. I would have expected that any bindings that use the old `foo` (or have the old `foo` in their call graph) would be cleared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 12 20:28:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Feb 2017 20:28:24 -0000 Subject: [GHC] #13270: Make Core Lint faster In-Reply-To: <047.f4267b5b37a515c1dcc3b3bf7fcfc3c6@haskell.org> References: <047.f4267b5b37a515c1dcc3b3bf7fcfc3c6@haskell.org> Message-ID: <062.39fcab4fd5c5e80569bc76d8db0cebe7@haskell.org> #13270: Make Core Lint faster -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): That ''is'' a bit of a surprise. I suppose it could be that Lint forces some thunks that would otherwise do un-forced. So it could perhaps not be Lint itself. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 01:12:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 01:12:17 -0000 Subject: [GHC] #12409: Unboxed tuples have no type representations In-Reply-To: <046.32a785a6183ec0ab7732a4ef59760aa4@haskell.org> References: <046.32a785a6183ec0ab7732a4ef59760aa4@haskell.org> Message-ID: <061.ddc43890a11b72d841d2aea446c3a1bc@haskell.org> #12409: Unboxed tuples have no type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11722 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #11722 Comment: This is a duplicate of #11722. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 01:12:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 01:12:52 -0000 Subject: [GHC] #11722: No TypeRep for unboxed tuples In-Reply-To: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> References: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> Message-ID: <062.107c6b6b65dae1271d3d97e5958f71b4@haskell.org> #11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable Operating System: 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): #12409 is a duplicate of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 01:13:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 01:13:03 -0000 Subject: [GHC] #11722: No TypeRep for unboxed tuples In-Reply-To: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> References: <047.62aa410ace38ef8cf0e4ab854da20597@haskell.org> Message-ID: <062.84649b8979888136f701afa529a2cd52@haskell.org> #11722: No TypeRep for unboxed tuples -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12409 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12409 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 02:02:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 02:02:31 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X Message-ID: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> #13278: test 'debug' is timing out on OS X ----------------------------------------+--------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 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: ----------------------------------------+--------------------------------- All the builds I've seen are failing due to a timeout of the `debug` test, apparently while running the `./debug` executable. Strange since it looks like it ought to finish very quickly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 02:03:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 02:03:33 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X In-Reply-To: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> References: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> Message-ID: <062.c2499abdd72ae31f629ab0c1b45845af@haskell.org> #13278: test 'debug' is timing out on OS X ---------------------------------+---------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 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 rwbarton): * owner: (none) => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 02:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 02:53:42 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X In-Reply-To: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> References: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> Message-ID: <062.123026fd07b8e61ed768c83759080208@haskell.org> #13278: test 'debug' is timing out on OS X ---------------------------------+---------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): It seems to be stuck in a loop between 0x100001110 and 0x100001124, {{{ debug`ZCMain_main_info: 0x100001110 <+0>: leaq -0x10(%rbp), %rax 0x100001114 <+4>: cmpq %r15, %rax 0x100001117 <+7>: jb 0x100001126 0x10000111d: nop 0x10000111e: nop 0x10000111f: nop 0x100001120: nop 0x100001121: nop 0x100001122: nop 0x100001123: nop debug`n27q: 0x100001124 <+0>: jmpq *(%rbx) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 03:24:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 03:24:34 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X In-Reply-To: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> References: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> Message-ID: <062.7cbe0b2ec62d7e660baa25f7465981b4@haskell.org> #13278: test 'debug' is timing out on OS X ---------------------------------+---------------------------------------- Reporter: rwbarton | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 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 rwbarton): * owner: rwbarton => bgamari Comment: We're generating code like {{{ .globl _ZCMain_main_info _ZCMain_main_info: Lc27e: n27l: leaq -16(%rbp),%rax cmpq %r15,%rax jb Lc27f Lc27e_end: Lc27g: n27s: subq $8,%rsp n27u: movq %r13,%rax movq %rbx,%rsi movq %rax,%rdi ... }}} and the symbols `n27l`, `n27s` etc. are not local symbols, so the linker seems to think that `n27s` is the end of `_ZCMain_main_info` and is stripping out the "dead code". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 03:25:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 03:25:38 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X In-Reply-To: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> References: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> Message-ID: <062.4d9fe786f32c4cb5d7df8cb03c56cc50@haskell.org> #13278: test 'debug' is timing out on OS X ---------------------------------+---------------------------------------- Reporter: rwbarton | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3135 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3135 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 06:09:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 06:09:25 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.ee5f4059bbedc535d05856d5513b6b72@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T8598 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I have come across an example where adding a new item to the lattice is actually useful: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Float(fun) where import GHC.Exts import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) fun :: Double -> Double fun x@(D# x#) | x == 0 = 0 | otherwise = case isDoubleFinite x of I# y# -> case decodeDoubleInteger x# of (# i, j #) -> fun (D# (encodeDoubleInteger i (y# +# j))) foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} Here `fun` is a tail-recursive function, and I think it can be CPRed just fine. However the current GHC fails to give `fun` a CPR property because it removes too much information in `deferAfterIO`. Specifically: 1. In the first iteration of the fixpoint calculation, the recursive to call to `fun` gets the CPR result of `Diverges`. 2. However, the case expression that scrutinizes `isDoubleFinite x` causes a call to `deferAfterIO`, which turns the CPR result to `Dunno NoCPR`. 3. This in turn means the whole function doesn't get any useful CPR property. If we had `ExitCPR` (or `Exits` to match the current naming convention) in the lattice, then the step (2) would have returned `Exits` instead of `Dunno NoCPR`, and allowed `fun` to get a useful CPR property. I don't know how often this comes up in practice. With nested CPR, this will become a much bigger problem because it essentially means no tail- recursive IO function can get a useful CPR property. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 06:10:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 06:10:46 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.48d54e4a8a42393059cd8721ed7c57b5@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T8598 Blocked By: | Blocking: Related Tickets: #1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) * related: => #1600 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 06:13:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 06:13:37 -0000 Subject: [GHC] #13279: Check known-key lists Message-ID: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> #13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- I noticed that `fmap` (for example) has a known key {{{#!hs fmapName = varQual gHC_BASE (fsLit "fmap") fmapClassOpKey fmapClassOpKey = mkPreludeMiscIdUnique 173 }}} but its `RdrName` doesn't refer to it. {{{#!hs fmap_RDR = varQual_RDR gHC_BASE (fsLit "fmap") }}} Is there a reason for this? If not, it seems likely that we could get a bit of a speed-up by using `fmapName` here. We may also consider making `liftA2` known-key for `Traversable` deriving. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 06:45:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 06:45:51 -0000 Subject: [GHC] #13236: Improve floating for join points In-Reply-To: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> References: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> Message-ID: <061.ee90b3af5a0ef4fe08e3264d1c5b42c4@haskell.org> #13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): **Question 1.** For nullary join points, yes, this would definitely be a better way to “ruin” them. It would just be a matter of calling `lvlMFE` instead of `lvlExpr` in `lvlFloatRhs` when looking at the RHS of a join point. For going to top level, we could do something similar to perform the operation (have the join point delegate to a function), but to make the decision we still need special logic saying the function must be going either to top level or not above the join ceiling. Otherwise we can end up with: {{{ f a b = joinrec j1 x y = join j2 z = ... a ... b ... {- no x or y -} in ... in ... }}} becoming: {{{ f a b = let h z = ... a ... b ... joinrec j1 x y = join j2 z = h z in ... in ... }}} at which point `j2` goes away and is effectively “ruined” just as if we weren't careful with join points at all. **Question 2.** It happens, for instance in `circsim`, where a case branch that's a jump gets MFE'd. There's no more or less reason to float an MFE as a join point than to float an join point at all, AFAIK. **Question 3.** There's a Note [Join points] in `FloatOut` (maybe should be `SetLevels` instead?) with an example. Note that the simplifier wouldn't be able to do the floating to flatten the nested cases, since it would need to know the free variables of `j2` and `j3` to float them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 07:23:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 07:23:04 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.eb1d67a301ae9c9339756fa5f0c64bf3@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): It seems like the above results were bogus because it used libraries compiled with the wrong compiler (I had `stage=2` in build.mk. I removed it and typed `make`. Is it not sufficient to cause a full build?). After a clean build, the allocation numbers look very good: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- compress2 +2.0% -0.9% 0.170 0.170 -3.7% fft2 +1.0% -0.2% 0.078 0.078 0.0% fluid +2.1% -0.4% 0.006 0.006 0.0% gamteb +0.4% -4.5% 0.032 0.032 0.0% gcd +0.7% -21.4% 0.046 0.046 0.0% infer -0.1% -1.2% 0.054 0.054 0.0% integer +1.0% -1.5% -15.0% -15.0% 0.0% mandel +1.0% -24.4% 0.051 0.051 0.0% rfib +1.0% -0.3% 0.012 0.012 0.0% solid +0.4% -6.6% 0.130 0.131 0.0% -------------------------------------------------------------------------------- Min -0.2% -24.4% -21.1% -21.3% -3.7% Max +2.1% +0.1% +39.3% +39.3% +17.3% Geometric Mean +0.2% -0.7% -4.9% -4.9% +0.1% }}} Should I worry about the increase in the code size? If not I'll clean up the branch and submit a Diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 07:54:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 07:54:28 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.8a38d650da88e77f4f1b54e04b9ae3a1@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): Thanks—glad to hear it was (so far) a simple fix … -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 09:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 09:03:16 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.6a8d7770a1baf061dfa2ba5d93ad5e53@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > (I had stage=2 in build.mk. I removed it and typed make. Is it not sufficient to cause a full build?). make won't necessarily rebuild your libraries, due to GHC's recompilation avoidance. It knows about changes in the source code and the flags, but it doesn't know about changes in GHC itself. So when I'm making measurements like this, I always delete the library object files manually: ``` find libraries/*/dist-install | grep 'o$' | xargs rm ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 10:06:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 10:06:45 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.f91df692ad86179d2f28e1d34312d12a@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:61 simonmar]: > make won't necessarily rebuild your libraries, due to GHC's recompilation avoidance. Oh I see... Thank you for the tip! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 12:28:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 12:28:21 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.501f0cabb2bfdf8dd62d95a17b75900c@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #11068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): [https://github.com/fpco/store/pull/94 Here] is a PR for `store` which implements the suggested change in comment:20. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 14:31:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 14:31:52 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.9a5ed4fe668254dbd68ef418b9323533@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: TypeFamilies, | SafeHaskell hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): rwbarton's comment:16 looks very plausible. I can't quite convince myself that it's right, but I also can't think of a counterexample. It's certainly easier to explain (and likely to implement) than many other solutions mentioned here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 15:19:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 15:19:47 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.cdafec5c3becba84ebcb946c2479e0d1@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If, from your perspective, the added complexity is worth it, then this looks OK to me. What's frustrating here is that we don't really need a new `Abstract` equality relation: the current `Phantom` one works fine. All we need is a new role ''annotation''. Is it worth creating a new `data RoleAnnotation = Abstract | Concrete Role`? Perhaps. You would also then need to be careful about uses of `tyConRoles` and `tyConRolesX`, as they are currently used both for construction and decomposition -- up until this proposal, both directions were happy with the same roles. I do agree that your approach is type safe. But I have to wonder if there isn't a simpler solution somehow, as I'm hesitant to advocate yet another wrinkle to the role system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 15:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 15:21:09 -0000 Subject: [GHC] #13279: Check known-key lists In-Reply-To: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> References: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> Message-ID: <060.c056e2cca7a55a6b5102752dbf7b0452@haskell.org> #13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 RyanGlScott): This sounds like a good idea. Are we sure that `valQual_RDR` is always the same as `nameRdrName (varQual ...)`? If so, I say go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 15:21:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 15:21:13 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it reduces away In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.4ba6aa1919c3f3f43a7d8a52a8fe281c@haskell.org> #13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed. But vanilla type synonyms are much simpler than type families. It's all a judgment call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 15:26:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 15:26:32 -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.1e77e52c3cc0409e209c60c79aaf2a62@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 19:42:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 19:42:12 -0000 Subject: [GHC] #13215: Panic: push_bang_into_newtype_arg In-Reply-To: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> References: <042.4ec3c670fc0e806ddb2de48bdf2a55dc@haskell.org> Message-ID: <057.3f78ae9b9ca0f9a4fac5ec28c3314c39@haskell.org> #13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3057 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed Comment: Merged as 062f112388ac879dc78a9a0c5a947894d20cd899 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 19:46:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 19:46:33 -0000 Subject: [GHC] #12429: Pattern synonym parse error should recommend enabling extension In-Reply-To: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> References: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> Message-ID: <064.be7fb8582702e30da4502b9e8fe3fd02@haskell.org> #12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | PatternSynonyms, 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 mpickering): * keywords: PatternSynonyms => PatternSynonyms, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 13 22:03:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Feb 2017 22:03:12 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.21a666f08a872b1991c9b8ab5df6ec21@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: backpack, | TypeFamilies, hs-boot Operating System: 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): dcoutts points out a use case for type family instances in hsig files here: https://github.com/haskell/bytestring/issues/102 It should be easier to implement for hsig because we don't need to equate any coercions just check that the equality holds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 00:06:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 00:06:33 -0000 Subject: [GHC] Trac email verification for user: AaronNGray Message-ID: <20170214000633.3DDB23A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: AaronNGray Verification Token: bRId-8Lg -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 02:10:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 02:10:29 -0000 Subject: [GHC] #13280: Consider deriving more Foldable methods Message-ID: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> #13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- We currently derive `foldMap` and `foldr`, but some others may deserve attention as well. * The most critical spots are probably `length` and `null`. Deriving these instead of using the defaults can change the orders of growth! Given `data Tree a = Bin !(Tree a) a !(Tree a) | Tip`, we surely don't want `null` to traverse the whole spine of the tree when it's quite immediately obvious that `Bin` is never null. And if a constructor contains a type with a very efficient `length` or `null` implementation (e.g., one that stores its own size), we certainly want to use that. * `foldl` typically ends up with rather different code than `foldr` (for a recursive type) even after simplification. We need to check whether this has a performance impact, but my bet is that it will in cases where the optimizer can't understand what's going on well enough. * `foldl'` and `foldr'` are a bit tricky. Ideally, if we have something like `data T a = C (G a) a | ...` then we'd like to be able to use `G`'s `foldl'` definition to define `T`'s. Unfortunately, different types in the wild have different `foldl'` semantics (and indeed the semantics for `[]` changed by mistake fairly recently). So we have to decide to what extent the derived semantics should depend on the choices of included types. I think we should probably just depend, because that seems likely what people will expect and want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 02:10:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 02:10:42 -0000 Subject: [GHC] #13280: Consider deriving more Foldable methods In-Reply-To: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> References: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> Message-ID: <060.7c47faf46cff0bb60726091cbb27c79c@haskell.org> #13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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 dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 10:14:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 10:14:56 -0000 Subject: [GHC] #13279: Check known-key lists In-Reply-To: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> References: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> Message-ID: <060.3fec2c9af79cf69c7b3442ec9e529fd9@haskell.org> #13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 simonpj): Yes go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 10:25:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 10:25:38 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.bf4774c6fe4ca7f821dde7b8332073af@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T8598 Blocked By: | Blocking: Related Tickets: #1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): For pure ccalls like this one we have no business messing with IO at all. I'd love to implement the first bullet of comment:2. What you say may also be true of tail-recursive functions that ''do'' perform IO, but there would be fewer cases where it mattered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 10:52:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 10:52:31 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.b64bb40baaa921690871623f7d9cbf9a@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good looking numbers esp for mandel, gcd. Can you dig in to see what is really happening there? How does the inner loop look? For code size, it's worth investigating to get insight. Look at the "module sizes" in the nofib-analyse log, and take a look at modules that got significantly bigger. Is that code-size increase because of an actual optimisation or is it just accidental? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 10:59:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 10:59:56 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.421c3afe971ae5a75c0ffd882c40acfd@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) 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 simonpj): Let's just do (1) for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 13:45:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 13:45:31 -0000 Subject: [GHC] #13280: Consider deriving more Foldable methods In-Reply-To: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> References: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> Message-ID: <060.f0d370db200b1850b21cf3246093668c@haskell.org> #13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:17:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:17:05 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.b9e401222813c3a0d26a76a918c90edc@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, I can't reproduce this either with a regular GHC HEAD. I wonder if having a profiled GHC HEAD makes a difference, as I noticed in your log that you were compiling a file with the suffix `.p_o`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:52:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:52:42 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X In-Reply-To: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> References: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> Message-ID: <062.bf8e4b6e29457b0c339ba8affbc5ce82@haskell.org> #13278: test 'debug' is timing out on OS X ---------------------------------+---------------------------------------- Reporter: rwbarton | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3135 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:54:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:54:23 -0000 Subject: [GHC] #13278: test 'debug' is timing out on OS X In-Reply-To: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> References: <047.f6cd0efced2f31eb64590c66feeafc6e@haskell.org> Message-ID: <062.98e6854e00b5f6dac9dce3883f65c271@haskell.org> #13278: test 'debug' is timing out on OS X ---------------------------------+---------------------------------------- Reporter: rwbarton | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3135 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"2d6e91eab9391210b8b816d9664407f246ef30e4/ghc" 2d6e91e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d6e91eab9391210b8b816d9664407f246ef30e4" Debug: Use local symbols for unwind points (#13278) While this apparently didn't matter on Linux, the OS X toolchain seems to treat local and external symbols differently during linking. Namely, the linker assumes that an external symbol marks the beginning of a new, unused procedure, and consequently drops it. Fixes regression introduced in D2741. Test Plan: `debug` testcase on OS X Reviewers: austin, simonmar, rwbarton Reviewed By: rwbarton Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3135 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:54:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:54:23 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.36e5695ff0c9470c2297bc587c265ede@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bollu Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3129 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"60c49861465015659a25542692b6d259667759e5/ghc" 60c4986/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60c49861465015659a25542692b6d259667759e5" Typecast covers entire expression to fix format warning. - Fixes (#12636). - changes all the typecasts to _unsinged long long_ to have the format specifiers work. Reviewers: austin, bgamari, erikd, simonmar, Phyx Reviewed By: erikd, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3129 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:54:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:54:23 -0000 Subject: [GHC] #13132: Compilation fails with a panic: get_op runContT In-Reply-To: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> References: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> Message-ID: <062.8533983b0209c2d7681b31bfdf7278dd@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_compile/T13132, | overloadedrecflds/should_fail/T13132_duplicaterecflds Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985, Wiki Page: | Phab:D3126 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2484d4dae65c81f218dcfe494b963b2630bb8fa6/ghc" 2484d4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2484d4dae65c81f218dcfe494b963b2630bb8fa6" Refactor renaming of operators/sections to fix DuplicateRecordFields bugs A variety of panics were possible because the get_op function in RnTypes didn't handle the possibility that its argument might be an ambiguous record field. I've made its return type more informative to correctly handle occurrences of record fields. Fixes Trac #13132. Test Plan: new test overloadedrecflds/should_fail/T13132_duplicaterecflds Reviewers: bgamari, simonpj, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3126 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:57:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:57:16 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.95a29d162449add7d178ca74b15ef62a@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3129 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bollu => (none) * status: patch => new * milestone: => 8.2.1 Comment: Phyx may have a point in comment:5 so I'm going to leave this open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 15:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 15:59:12 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.c0b0c0f4fe33ca11afc825e2d70b9f01@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged in, {{{ commit c3bbd1afc85cd634d8d26e27bafb92cc7481667b Author: vivid-synth Date: Tue Feb 14 09:51:54 2017 -0500 Allow type defaulting for multi-param type classes with ExtendedDefaultRules Expressions like the following will now typecheck: ``` data A x = A deriving Show class ToA a x where toA :: a -> A x instance ToA Integer x where toA _ = A main = print (toA 5 :: A Bool) ``` The new defaulting rules are Find all the unsolved constraints. Then: * Find those that have exactly one free type variable, and partition that subset into groups that share a common type variable `a`. * Now default `a` (to one of the types in the default list) if at least one of the classes `Ci` is an interactive class Reviewers: goldfire, bgamari, austin, mpickering, simonpj Reviewed By: bgamari, simonpj Subscribers: mpickering, simonpj, goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2822 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:03:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:03:54 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.c283ffcb3dd208f5bad9e63285ad6a34@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged 2f1017b924740e66f093b0baba62ac0b1528abf8, {{{ commit 2f1017b924740e66f093b0baba62ac0b1528abf8 Author: Tamar Christina Date: Tue Feb 14 09:44:53 2017 -0500 Fix ExtraSymbols jump table on Windows. This corrects the `jump islands` calculations for Windows. The code was incorrectly creating a new entry for every `usage` of a symbol instead of every used symbol. e.g. if a symbol is used 5 times it used to create 5 jump islands. This is incorrect and not in line with what the `ELF` and `Mach-O` linkers do. Also since we allocate `n` spaces where `n` is number of symbols, we would quickly run out of space and abort. Test Plan: ./validate Reviewers: simonmar, hvr, erikd, bgamari, austin Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3026 }}} Phyx, does this resolve this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:04:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:04:04 -0000 Subject: [GHC] #13113: Runtime linker errors with CSFML on Windows In-Reply-To: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> References: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> Message-ID: <065.ad917c630af37d7aa1ff566231fa2e59@haskell.org> #13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged 2f1017b924740e66f093b0baba62ac0b1528abf8, {{{ commit 2f1017b924740e66f093b0baba62ac0b1528abf8 Author: Tamar Christina Date: Tue Feb 14 09:44:53 2017 -0500 Fix ExtraSymbols jump table on Windows. This corrects the `jump islands` calculations for Windows. The code was incorrectly creating a new entry for every `usage` of a symbol instead of every used symbol. e.g. if a symbol is used 5 times it used to create 5 jump islands. This is incorrect and not in line with what the `ELF` and `Mach-O` linkers do. Also since we allocate `n` spaces where `n` is number of symbols, we would quickly run out of space and abort. Test Plan: ./validate Reviewers: simonmar, hvr, erikd, bgamari, austin Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3026 }}} Phyx, does this resolve this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:05:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:05:53 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.6c14ce193425359a37c2c963a8748322@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3129 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollu): I'm not sure what the expected solution is for the underflow bug. If Phyx / bgmari have ideas, I'd be glad to implement it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:13:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:13:15 -0000 Subject: [GHC] #11031: Record Pattern Synonym Cleanup In-Reply-To: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> References: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> Message-ID: <064.057db2a962195c4e759eb76edc305417@haskell.org> #11031: Record Pattern Synonym Cleanup -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: newcomer => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:16:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:16:37 -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.36ffe539b7d1f34e14df8fe38c47c3b2@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 bgamari): * cc: alanz (added) Comment: Adding alanz who has done some work in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:25:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:25:29 -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.1c38ff363ffbbc0b41a46890bc518266@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: #13238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * related: => #13238 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:26:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:26:22 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.530340d280fa335fe73a0be4aede8e1f@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Yep, a profiled GHC HEAD is crucial here. I couldn't reproduce this with a profiled 8.0.2, but with a profiled GHC HEAD, I get: {{{ $ cabal build Building aws-0.16... Preprocessing library aws-0.16... [69 of 78] Compiling Aws.DynamoDb.Core ( Aws/DynamoDb/Core.hs, dist/build/Aws/DynamoDb/Core.p_o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170213 for x86_64-unknown-linux): completeCall $wloop_length_s1bOu Stop[BoringCtxt] Int# -> Int# -> Int Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1197:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1201:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1598:9 in ghc:Simplify CallStack (from -prof): SimplCore.SimplTopBinds (compiler/simplCore/SimplCore.hs:729:29-64) SimplCore.Simplify (compiler/simplCore/SimplCore.hs:426:40-55) HscMain.Core2Core (compiler/main/HscMain.hs:1170:7-42) HscMain.hscSimplify' (compiler/main/HscMain.hs:(1167,1)-(1170,42)) HscMain.finish (compiler/main/HscMain.hs:(728,1)-(740,20)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(639,1)-(694,32)) GhcMake.upsweep_mod.compile_it (compiler/main/GhcMake.hs:(1380,13)-(1382,66)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1328,1)-(1482,49)) GhcMake.parUpsweep_one.withSem (compiler/main/GhcMake.hs:1104:13-66) GhcMake.parUpsweep_one (compiler/main/GhcMake.hs:(1009,1)-(1164,65)) GhcMake.parUpsweep.\.spawnWorkers.\.\ (compiler/main/GhcMake.hs:(867,43)-(918,49)) GhcMake.parUpsweep.\.spawnWorkers.\ (compiler/main/GhcMake.hs:(867,13)-(918,49)) GhcMake.parUpsweep.\.spawnWorkers (compiler/main/GhcMake.hs:(866,11)-(918,49)) GhcMake.parUpsweep.\.finallySyncSession (compiler/main/GhcMake.hs:(832,9)-(834,30)) GhcMake.parUpsweep.\ (compiler/main/GhcMake.hs:(829,62)-(949,44)) GhcMake.parUpsweep (compiler/main/GhcMake.hs:(796,1)-(979,36)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(351,9)-(352,41)) GhcMake.load'.checkHowMuch (compiler/main/GhcMake.hs:(233,9)-(235,27)) GhcMake.load' (compiler/main/GhcMake.hs:(210,1)-(439,38)) GhcMake.load (compiler/main/GhcMake.hs:(202,1)-(204,44)) GHC.withCleanupSession (compiler/main/GHC.hs:(450,1)-(459,37)) GHC.runGhc (compiler/main/GHC.hs:(425,1)-(430,26)) GHC.defaultErrorHandler (compiler/main/GHC.hs:(365,1)-(397,7)) 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 Feb 14 16:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:30:12 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.ef16c315a06f419e2d40b6971aa70232@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.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: 12143 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollu): * owner: simonmar => bollu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 16:30:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 16:30:42 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.94ed5e4d4b8a026790c3afbc98b3e1ce@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollu): * owner: bollu => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 19:27:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 19:27:55 -0000 Subject: [GHC] Trac password reset for user: ethercrow Message-ID: <20170214192755.502BC3A583@ghc.haskell.org> Your Trac password has been reset. Here is your account information: Login URL: Username: ethercrow Password: j00QxdHA -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 19:53:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 19:53:52 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.b6d443c847e0e85a6a690ba06579d81a@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ethercrow Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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 ethercrow): * owner: (none) => ethercrow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 20:54:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 20:54:27 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.7d59f8150179cf0870396e63ea3bfe7a@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, yes, that would make sense. Good catch, RyanGlScott! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 21:44:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 21:44:42 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.89ba6ffa0abe2cb92a6cf3b27aea0dac@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): No, this one requires a final fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 21:52:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 21:52:29 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.dfdbd2e959d6cbcf1d47162a389cdafa@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3129 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It may be that it isn't a problem. In case it is, we should add an assert before `censuses[era].void_total -= size;`. `assert (censuses[era].void_total >= size);` at least this way, if it is a problem we'll trigger it. if it's not it also makes it clear to the next person that we've thought about it and it's not an issue. if it turns out to be a problem, then we should replace `ssize_t` with a normal signed type like `uint64_t` or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 21:54:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 21:54:21 -0000 Subject: [GHC] #13113: Runtime linker errors with CSFML on Windows In-Reply-To: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> References: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> Message-ID: <065.8989b923c166f95249469ea2d6850796@haskell.org> #13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): No, it requires Phab:D3028 before it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 21:57:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 21:57:47 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.92b21cdebb5559a7b937851c7ccfc6fe@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 Ben Gamari ): In [changeset:"bedcb71659253bb8ab5d449df8e3ee884cc85d46/ghc" bedcb71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bedcb71659253bb8ab5d449df8e3ee884cc85d46" Check local type family instances against all imported ones We previously checked type family instance declarations in a module for consistency with all instances that we happened to have read into the EPS or HPT. It was possible to arrange that an imported type family instance (used by an imported function) was in a module whose interface file was never read during compilation; then we wouldn't check consistency of local instances with this imported instance and as a result type safety was lost. With this patch, we still check consistency of local type family instances with all type family instances that we have loaded; but we make sure to load the interface files of all our imports that define family instances first. More selective consistency checking is left to #13102. On the other hand, we can now safely assume when we import a module that it has been checked for consistency with its imports. So we can save checking in checkFamInstConsistency, and overall we should have less work to do now. This patch also adds a note describing the Plan for ensuring type family consistency. Test Plan: Two new tests added; harbormaster Reviewers: austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: ggreif, thomie Differential Revision: https://phabricator.haskell.org/D2992 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 21:57:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 21:57:47 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.71c346bbfa867a4aa4940a6420af043d@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 Ben Gamari ): In [changeset:"f90e61ad6e5fa0655185f14ca128d507e489c4b7/ghc" f90e61a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f90e61ad6e5fa0655185f14ca128d507e489c4b7" Make deSugarExpr use runTcInteractive Preparation for #13102, which needs to add more logic to runTcInteractive, which would need to be duplicated in deSugarExpr. In order to break an import cycle, I had to move "Dependency/fingerprinting code" to a new module DsUsage; which seems sensible anyways. Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3125 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 14 22:31:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Feb 2017 22:31:28 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.4c6f9e7e09107faa72fef95444bf97c4@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #11068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting! It looks to me as if the new behaviour is more faithfully following what the user said than the old behaviour. In this case, it is inlining `$gdm_size Foo $dStoreFoo` at every call of `size` at type `Foo`; and that's just what you'd expect from an INLINE pragma on the generic default method of `Store`. So maybe that was a bug in the old version, now fixed. And indeed, refraining from inlining the entire body of `size` at every call site seems like a good thing. Case closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 02:17:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 02:17:00 -0000 Subject: [GHC] Trac password reset for user: bgamari-test Message-ID: <20170215021700.136F83A583@ghc.haskell.org> Your Trac password has been reset. Here is your account information: Login URL: Username: bgamari-test Password: 3jbxNkmL -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 08:57:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 08:57:34 -0000 Subject: [GHC] #13281: Linting join points Message-ID: <046.384b28181188b76e598e4ffd0bb5c6fd@haskell.org> #13281: Linting join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Core Lint should check the polymorphic invariant on join points. See (4) in `Note [Invariants on join point]` in `CoreSyn`, and `chekValidJoinPointType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 15:00:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 15:00:42 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.39010049e85cf78f9c70f002f88f2908@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #11068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I honestly don't think there's a consistent rule that you shouldn't inline any default method implementations. Rather, this is a very particular case where inlining a chain of `GHC.Generics`-related instance methods together leads to high memory usage, which feels more like a bug than anything. My vote is to close this and pursue the discussion in #5642 and #11068, where this behavior has been observed before. Feel free to reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 15:01:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 15:01:36 -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.47f65739aab50a611aab790218393276@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13059 Comment: See also #13059 for an example of `GHC.Generics`-related memory blowup in the `store` library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 15:03:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 15:03:05 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.a93766ef11826a1cd457224ba5e99400@haskell.org> #13059: High memory usage during compilation -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc2 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #5642, #11068 => #5642, #9630 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 15:03:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 15:03:57 -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.249827e0790d3141203c32e76cad5ec5@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics 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): #13059 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #9583, #10293 => #9583, #10293, #13059 Comment: See also #13059 for an example of GHC.Generics-related memory blowup in the `store` library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 15:30:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 15:30:09 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.ef39ae4088e747932c648c66eaa094c6@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've managed the problem to isolate this smaller example: {{{#!hs module Bug where ------------------------------------------------------------------------------- import qualified Data.ByteString.Base64 as Base64 import qualified Data.ByteString.Char8 as B import qualified Data.Set as S import qualified Data.Text as T import qualified Data.Text.Encoding as T data DValue = DBinary B.ByteString | DBool Bool | DBoolSet (S.Set Bool) ------------------------------------------------------------------------------- class DynSize a where dynSize :: a -> Int instance DynSize DValue where dynSize (DBool _) = 8 dynSize (DBoolSet s) = sum $ map (dynSize . DBool) $ S.toList s dynSize (DBinary bs) = T.length . T.decodeUtf8 $ Base64.encode bs }}} You'll need to run `cabal install base64-bytestring text --enable-library- profiling` beforehand. Then you can reproduce it like so: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -O2 -prof -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170213 for x86_64-unknown-linux): completeCall $wloop_length_s87d Stop[BoringCtxt] Int# -> Int# -> Int Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1197:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1201:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1598:9 in ghc:Simplify CallStack (from -prof): SimplCore.SimplTopBinds (compiler/simplCore/SimplCore.hs:729:29-64) SimplCore.Simplify (compiler/simplCore/SimplCore.hs:426:40-55) HscMain.Core2Core (compiler/main/HscMain.hs:1170:7-42) HscMain.hscSimplify' (compiler/main/HscMain.hs:(1167,1)-(1170,42)) HscMain.finish (compiler/main/HscMain.hs:(728,1)-(740,20)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(639,1)-(694,32)) GhcMake.upsweep_mod.compile_it (compiler/main/GhcMake.hs:(1380,13)-(1382,66)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1328,1)-(1482,49)) GhcMake.upsweep.upsweep' (compiler/main/GhcMake.hs:(1197,3)-(1296,91)) GhcMake.upsweep (compiler/main/GhcMake.hs:(1189,1)-(1296,91)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(351,9)-(352,41)) GhcMake.load'.checkHowMuch (compiler/main/GhcMake.hs:(233,9)-(235,27)) GhcMake.load' (compiler/main/GhcMake.hs:(210,1)-(439,38)) GhcMake.load (compiler/main/GhcMake.hs:(202,1)-(204,44)) GHC.withCleanupSession (compiler/main/GHC.hs:(450,1)-(459,37)) GHC.runGhc (compiler/main/GHC.hs:(425,1)-(430,26)) GHC.defaultErrorHandler (compiler/main/GHC.hs:(365,1)-(397,7)) 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 Feb 15 19:48:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 19:48:45 -0000 Subject: [GHC] #13282: Introduce fast path through simplifier for static bindings Message-ID: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> #13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- It's not uncommon for early simplifier runs to float out a large number of "static data" bindings from a user program to the top-level. Here we will consider a top-level binding to be "static" if its RHS consists of a data constructor applied to zero or more other static bindings. This floating is quite helpful as static top-levels are represented easily as static code in object code. It also opens an interesting possibility: we know (with a few potential caveats discussed later) no further simplification of these bindings is possible. However, the simplifier currently does not take advantage of this latter fact: currently the simplifier will dutifully rebuild all bindings on every iteration. This work is wasted effort. I think it would be helpful to track the "static-ness" of top-level bindings and teach the simplifier and various analyses to ignore bindings so-marked. Also, there is one caveat here: it is currently possible for users to write rules whose LHSs are headed by a data constructor. This means that further simplification of the bindings which we deemed above as "static" **is** possible. There are two ways of dealing with this, a. Forbidding data cons in the head of a RULE's LHS b. Check the rule-base for matching rules matching a datacon as "static" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 19:53:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 19:53:04 -0000 Subject: [GHC] #13282: Introduce fast path through simplifier for static bindings In-Reply-To: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> References: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> Message-ID: <061.3df6e75faf6e98f1b594da15be51e365@haskell.org> #13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 19:57:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 19:57:20 -0000 Subject: [GHC] #13282: Introduce fast path through simplifier for static bindings In-Reply-To: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> References: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> Message-ID: <061.ad9e041031e11aa6af1aa9d2728af0cc@haskell.org> #13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 rwbarton): > Here we will consider a top-level binding to be "static" if its RHS consists of a data constructor applied to zero or more other static bindings. Minor amendments: - I think you only intend to allow ''saturated'' data constructor applications; though I'm not sure. - Literals should also be considered static. - What about type applications of polymorphic data constructors to type variables? E.g. {{{#!hs a :: [Maybe a] a = [Nothing] }}} desugars to {{{#!hs a :: forall a. [Maybe a] a = \ (@ a1) -> : @ (Maybe a1) (Nothing @ a1) ([] @ (Maybe a1)) }}} and it's static in the sense that it will be represented by static closures; but at the Core level, it involves a type variable `a1`. Do you consider this "static" in your sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 20:25:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 20:25:14 -0000 Subject: [GHC] #13282: Introduce fast path through simplifier for static bindings In-Reply-To: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> References: <046.915d332d66020931b980285e3b7e2ea2@haskell.org> Message-ID: <061.d7b11f46dc7edbe5d364d30e1edd20da@haskell.org> #13282: Introduce fast path through simplifier for static bindings -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): > Minor amendments: > * I think you only intend to allow saturated data constructor applications; though I'm not sure. > * Literals should also be considered static. Yes, I should have been more precise. I believe the right check is `exprIsConLike_maybe` and verifying that all of the value arguments are themselves binders or literals. > What about type applications of polymorphic data constructors to type variables? E.g. That is an interesting point; I think there is a reasonable argument to be made for considering type lambdas as static as well. This isn't what the patch (which has been a bit trickier than I thought due to unfoldings getting zapped in various unexpected places) currently implements though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 22:50:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 22:50:13 -0000 Subject: [GHC] #13283: T5435_dyn_asm fails with gold linker Message-ID: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> #13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | 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 tried validating with `ld.gold` as my system linker and one test failed: {{{ cd "./rts/T5435_dyn_asm.run" && $MAKE -s --no-print-directory T5435_dyn_asm T5435_dyn_asm failed with ['initArray1', 'initArray2', 'ctors2', 'ctors1', 'success'], see all.T for details }}} The expected output has `ctors1` and then `ctors2`. This looks like a bug in gold to me. ezyang, do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 22:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 22:50:52 -0000 Subject: [GHC] #12878: Use gold linker by default if available on ELF systems In-Reply-To: <047.c7ddb643b4ab18bdba2072ff5764699e@haskell.org> References: <047.c7ddb643b4ab18bdba2072ff5764699e@haskell.org> Message-ID: <062.46255ac5578f2e65d1096b656f668242@haskell.org> #12878: Use gold linker by default if available on ELF systems -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): See #13283 for a potential blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 15 23:56:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Feb 2017 23:56:11 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.3107ab6ef4660682f777dc48cb3bfe87@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * version: 8.0.1 => 8.0.2 Old description: > I've run into a very strange sort of memory leak it seems. GHC seems to > manage to allocate memory which I cannot get rid of no matter what I try > even after all references have disappeared. The allocated memory doesn't > show up in heap profiles but is still visibly allocated (as seen in ps or > pmap). > > I discovered this while investigating reports of large memory usage in > ghc-mod where this issue is forcing us to dump completion information in > a separate process to avoid the allocated memory sticking around for the > rest of the user's session. > > The attached test case demonstrates this problem by first calling > `getModuleInfo` for all modules in all visible packages and then just > looping forever in `main`. I would expect all memory GHC allocated to be > GC'd at this point but this does not happen. > > When run as > > {{{ > $ ./Leaky -hide-all-packages > }}} > > the test case consumes around 30M of memory on my system, if we however > load some large package, say GHC itself > > {{{ > $ ./Leaky -hide-all-packages -package ghc > }}} > > the program will consume around 2-300M of memory which are never > deallocated. The behaviour is not related to the loaded package though I > tried it with `Cabal` too with the same result though smaller memory > usage. > > At first I thought this might be related to large CAFs with IORefs inside > not being GCd for some reason so I tried calling `resetCAFs` from the RTS > before entering the loop. This however makes no difference whatsoever. I > also tried forcing a major GC just to be save to no avail. > > Next I speculated that maybe the allocated memory is beyond the GC's > control (malloc()ed or something) but looking at the memory map of the > process with `pmap $(pgrep Leaky)` I can see that the majority of the > memory usage I'm seeing comes from address `0x0000000200000000` which is > where the RTS allocates memory AFAIK. New description: I've run into a very strange sort of memory leak it seems. GHC seems to manage to allocate memory which I cannot get rid of no matter what I try even after all references have disappeared. The allocated memory doesn't show up in heap profiles but is still visibly allocated (as seen in ps or pmap). I discovered this while investigating reports of large memory usage in ghc-mod where this issue is forcing us to dump completion information in a separate process to avoid the allocated memory sticking around for the rest of the user's session. The attached test case demonstrates this problem by first calling `getModuleInfo` for all modules in all visible packages and then just looping forever in `main`. I would expect all memory GHC allocated to be GC'd at this point but this does not happen. When run as {{{ $ ./Leaky -hide-all-packages }}} the test case consumes around 30M of memory on my system, if we however load some large package, say GHC itself {{{ $ ./Leaky -hide-all-packages -package ghc }}} the program will consume around 2-300M of memory which is never deallocated. The behaviour is not related to the loaded package though I tried it with `Cabal` too with the same result though smaller memory usage. At first I thought this might be related to large CAFs with IORefs inside not being GCd for some reason so I tried calling `resetCAFs` from the RTS before entering the loop. This however makes no difference whatsoever. I also tried forcing a major GC just to be save to no avail. Next I speculated that maybe the allocated memory is beyond the GC's control (malloc()ed or something) but looking at the memory map of the process with `pmap $(pgrep Leaky)` I can see that the majority of the memory usage I'm seeing comes from address `0x0000000200000000` which is where the RTS allocates memory AFAIK. -- Comment: I can still reproduce this with 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:07:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:07:58 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.faeafc407889e5a6af236244e6d2cf40@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > markAllJoinsBad looks somewhat expensive You are right. It's ridiculously expensive, and there is a vastly easier way to do the job: keep track of the valid join points, not the invalid ones! Patch coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:13:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:13:37 -0000 Subject: [GHC] #13277: When type classes are redefined in GHCi bindings that use old instances are still accessible In-Reply-To: <044.c914dfe329327845e56ac7e6d4602a5b@haskell.org> References: <044.c914dfe329327845e56ac7e6d4602a5b@haskell.org> Message-ID: <059.0b32a078b3254fe4c1bb66169682ee29@haskell.org> #13277: When type classes are redefined in GHCi bindings that use old instances are still accessible -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | 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 simonpj): * status: new => closed * resolution: => invalid Comment: No, this is by design. Consiider {{{ Prelude> let x = 3 Prelude> let y = x+4 Preluce> (\x -> y) 72 8 Prelude> let x = "hello" Prelude> y 8 }}} The value of `y` is `x+4` where `x`'s value comes from the binding site of `y`. The fact that `x` now has a totally different value (72, or "hello" in the two examples) is irrelevant. Same with `f` above. Its value is 1 regardless of what other bindings you bring into scope subsequently. Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:18:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:18:35 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.6363e6b73fdd128744c679d326ee67d1@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Joachim, could you add the test case in comment:9 as a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:26:23 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.28a8fc68c564c548fe8708631958d198@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: lukemaurer (added) Comment: I've confirmed that this bug first appears after commit 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:56:52 -0000 Subject: [GHC] #13284: Incoherent instance solving is over-eager Message-ID: <046.b12140a214811442aff2cfd122cbc2ec@haskell.org> #13284: Incoherent instance solving is over-eager -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- danilo2 writes (originally in #9432 comment:1) {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE IncoherentInstances #-} -- the flag is niot needed by the example module Main where import Data.Typeable class CTest a b | a -> b where cTest :: a -> b -- this instance is choosen even if more specific is available! instance out~a => CTest a out where cTest = id instance CTest Int String where cTest _ = "test" main = do print $ typeOf $ cTest (5::Int) }}} The instance `CTest a out` even if more specific `(CTest Int String)` is in scope, which just breaks how `OverlappingInstances` work. If we disable the `IncoherentInstances` flag, the right one is selected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:57:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:57:18 -0000 Subject: [GHC] #13284: Incoherent instance solving is over-eager In-Reply-To: <046.b12140a214811442aff2cfd122cbc2ec@haskell.org> References: <046.b12140a214811442aff2cfd122cbc2ec@haskell.org> Message-ID: <061.4a080b48a924a7186947c14aa27d6a6d@haskell.org> #13284: Incoherent instance solving is over-eager -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There is a real difficulty with what you are asking for. The constraint solver sees a single 'wanted' constraint: {{{ [W] CTest Int alpha }}} where `alpha` is a unification variable standing for an as-yet-unknown type. It tries to solve it; and with `IncoherentInstances` it can do so with the `CTest a out` instance. But that's not what danilo2 wants. He wants the solver to leave it unsolved, and instead generate the 'derived' instance coming from the fundep. So we add the new constraint {{{ [D] alpha ~ String }}} Now we can solve `alpha := String`, so the original constraint becomes {{{ [W] CTest Int String }}} which can be solved with the `CTest Int String` instance. All this depends on waiting until some other unification happens, to render `[W] CTest Int alpha` soluble. But when shoudl we give up and use the `CTest out a` instance anyway? Suppose there wasn't a fundep on `CTest` and we had {{{ [W] CTest Int alpha [W] Boo [Tree (alpha, Int)] }}} and after a lot of work, applying instances etc, the second constraint simplifies to something that unifies `alpha := Int`. Aha! Now we can solve the first one. So you might say "solve using all rules EXCEPT incoherent instances, and THEN apply incoherent instances". But that isn't well defined. E.g. {{{ [W] C1 Int alpha [W] C2 Int alpha }}} Suppose both have incoherent instances. Should I solve the first with the incoherent instance (thereby, perhaps, fixing `alpha`)? Or the second? We might get quite different answers. You could say "well, just do your best; incoherence is, well, incoherent". So yes, I suppose we could take a bit more trouble to delay using incoherent instances. Would enough people care? I don't know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 00:58:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 00:58:03 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.f54cb5128456910ebbf41e439452015e@haskell.org> #9432: IncoherentInstances are too restricted -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes these are two distinct issues. I've made #13284 for comment:1. I don't really understand the problem in the Description. Does it not suffice to add the signature {{{ inferTypeBase :: InferType a => a -> Proxy a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 03:37:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 03:37:13 -0000 Subject: [GHC] #13285: Bug in GHC.Stack.callStack when used with sections Message-ID: <050.81951777fb2bcb194935732bc18dc469@haskell.org> #13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Since GHC {{{8.0.1}}} call stacks are not constructed consistently anymore. Specifically, no stack frames are added for call sites that use section syntax. This used to work with GHC {{{7.10.2}}}. I haven't tried with {{{7.10.3}}}. Call stacks are used in {{{hspec}}} and {{{HUnit}}} to attach location information to failing test cases. Moreover, it is somewhat common to use section syntax with {{{hspec}}}. This is why I describe the bug in the context of {{{hspec}}}. But first, I give minimal steps on how to reproduce without the need of any additional dependencies. = TL;DR Minimal steps to reproduce {{{ #!haskell -- Main.hs import GHC.Stack main :: IO () main = do foo 23 42 (`foo` 23) 42 foo :: HasCallStack => Int -> Int -> IO () foo _ _ = print (length . getCallStack $ callStack) }}} {{{ $ runhaskell Main.hs }}} expected output: {{{ 1 1 }}} actual output: {{{ 1 0 }}} = Description of the bug from a users perspective (in the context of Hspec) This section describes the bug in the context of {{{hspec}}}. If you already understand how this bug affects users and why this is problematic you may choose to skip this section. == A working example Looking at the following example {{{ #!haskell -- Spec.hs import Test.Hspec main :: IO () main = hspec $ do it "works for my use case" $ do 23 `shouldBe` 42 }}} call stacks work as expected: {{{ $ runhaskell Spec.hs ... Failures: Spec.hs:6: 1) works for my use case expected: 42 but got: 23 ... }}} The users sees a source locations that points him to the failing test case. == A slightly modified and broken example If we rephrase the above example using section syntax we get {{{ #!haskell -- Spec.hs import Test.Hspec main :: IO () main = hspec $ do it "works for my use case" $ do (`shouldBe` 42) 23 }}} and things suddenly go bad: {{{ $ runhaskell Spec.hs ... Failures: src/Test/Hspec/Expectations.hs:91: 1) works for my use case expected: 42 but got: 23 ... }}} The user expects to see the call site of {{{shouldBe}}}, that points him to the failing test case. But instead he gets an unhelpful location that points somewhere at the implementation of {{{hspec-expectations}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 04:36:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 04:36:03 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.618d79bcafb704fe87caa7c9d719bb84@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): In fact, I tried doing that right when you posted comment:9. I tried to modify so that unwanted floating would be detectable in the output by some carefully placed `trace`, but I did not manage that. (I dislike tests that grep in `-ddump-simpl`, they are too fragile.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 11:28:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 11:28:25 -0000 Subject: [GHC] #13286: Late floating of join points Message-ID: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> #13286: Late floating of join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this, from `GHC.Real`: {{{ GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> joinrec { $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> joinrec { $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# [LclId[JoinId(3)], Arity=3, Str=, Unf=OtherCon []] $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 }; } in jump $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> jump $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) }; } in jump $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} Note those two `joinrecs`. Neither has any free variables. So we could float them to top level, as ordinary functions, thus {{{ $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} Is this better? * Better before: the nested join points don't allocate a closure; but the top-level defns do build a (never used) closure and slow entry point. * Better after: the externally-visible function might inline more at call sites in other modules. So it's a bit moot. It has something of the flavour of the late lambda- lifting pass. For now I'm doing nothing; just recording the observation. The simple thing is not to float. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 12:54:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 12:54:36 -0000 Subject: [GHC] #13285: Bug in GHC.Stack.callStack when used with sections In-Reply-To: <050.81951777fb2bcb194935732bc18dc469@haskell.org> References: <050.81951777fb2bcb194935732bc18dc469@haskell.org> Message-ID: <065.c0e420923bf60c8f6727da5566d4b531@haskell.org> #13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 simonpj): * owner: (none) => simonpj Comment: I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 14:25:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 14:25:13 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.230b5c144512ac8debef8cbc525e9646@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6bab649bde653f13c15eba30d5007bef4a9a9d3a/ghc" 6bab649b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6bab649bde653f13c15eba30d5007bef4a9a9d3a" Improve checking of joins in Core Lint This patch addresses the rather expensive treatment of join points, identified in Trac #13220 comment:17 Before we were tracking the "bad joins". Now we track the good ones. That is easier to think about, and much more efficient; see CoreLint Note [Join points]. On the way I did some other modest refactoring, among other things removing a duplicated call of lintIdBndr for let-bindings. On teh }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 14:25:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 14:25:13 -0000 Subject: [GHC] #13285: Bug in GHC.Stack.callStack when used with sections In-Reply-To: <050.81951777fb2bcb194935732bc18dc469@haskell.org> References: <050.81951777fb2bcb194935732bc18dc469@haskell.org> Message-ID: <065.84ee694f05110e281933732f26c69fd3@haskell.org> #13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 Simon Peyton Jones ): In [changeset:"b8c29bc9ccd541478b6c1b9d04ca940b9d74cf96/ghc" b8c29bc9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b8c29bc9ccd541478b6c1b9d04ca940b9d74cf96" Use the correct origin in SectionL and Section R This fixes Trac #13285. The CallStack stuff is all driven by a CtOrigin of (OccurenceOf f), and we were instead using SectionOrigin. Boo! Easily fixed; and I did a little refactoring as usual. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 14:28:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 14:28:29 -0000 Subject: [GHC] #13286: Late floating of join points In-Reply-To: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> References: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> Message-ID: <061.7caa7110e54784e49e78fd0a28b7b23a@haskell.org> #13286: Late floating of join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another example is `simplCore/should_compile/spec-inline.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 14:29:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 14:29:44 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.676dea183115df2eb0661374b41cb6d4@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Reid, does this patch help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 14:30:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 14:30:37 -0000 Subject: [GHC] #13285: Bug in GHC.Stack.callStack when used with sections In-Reply-To: <050.81951777fb2bcb194935732bc18dc469@haskell.org> References: <050.81951777fb2bcb194935732bc18dc469@haskell.org> Message-ID: <065.aaed85ba730a1da004122d838ab4e56a@haskell.org> #13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | deSigar/should_run/T13285 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => deSigar/should_run/T13285 * status: new => merge * milestone: => 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 15:00:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 15:00:12 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.ac78c7275c2679c7ed2d69c8a6b28fd9@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great test case! I'm on it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 15:13:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 15:13:44 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux Message-ID: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting a executable like this: app -- arg1 +RTS -s -RTS arg2 Windows and Linux pass different arguments on to the application: * Windows: `["--","arg1","arg2"]` * Linux: `["--","arg1","+RTS","-s","-RTS","arg2"]` If we want uniform behavior we need to change one of these. Given the existence of the --RTS flag I'm not sure if the Linux behavior was intended however it matches the behavior you would expect in the *nix world nicely. Therefore changing the behavior on Windows would make more sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 15:18:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 15:18:55 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.c8c58a948a2278d22c5201b3498ed631@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 15:56:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 15:56:25 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.34047ebc2c8ae09ee1fbf563baef91a4@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.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 AndreasK): There is already a issue for reworking the argument parser: #4243 (Make a proper options parser for the RTS) Using a unified parser would certainly fix this behavior as well. There is also interesting behaviour with -rtsopts=none * `app -- +RTS arg1` get's silently ignored * `app +RTS arg1` gives a warning (as expected) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 15:58:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 15:58:35 -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.5388cb8f7920ab1fb1b6a3ba56bfca87@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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 AndreasK): 13287# is also an effect of difference in parsing between Windows and Linux which could be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 18:44:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 18:44:58 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.31a93b3d2dad530f455a37a4493ba125@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high * milestone: => 8.2.1 Comment: Thank you! I was baffled by this behavior in the context of a stack ticket (on phone, so not going to look for it now). With your hints I now understand more or less what is going on. The difference between `--` and `--RTS` is that the former is passed on to the program, while the latter is not. It's intentional and documented at least in the code which implements it, and I think in the user's guide also. Let's just fix this for 8.2 (should be a one line change) and worry about cleaning up the weird command line stuff we do on Windows after that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 22:16:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 22:16:09 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries Message-ID: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | 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: -------------------------------------+------------------------------------- We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We are preparing a patch to address these issues; it will point out the particular lines of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 22:28:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 22:28:31 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries In-Reply-To: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> References: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> Message-ID: <061.4be87ab52e0ac6998105e89eb0a4e933@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Description changed by j6carey: Old description: > We observed high resident set size well in excess of the `+RTS -M` limit > in a long-running, high data-volume Haskell application that Awake > Networks is deploying on a network appliance. > > We think that the current `GC.c` code has two bugs that, at least in > combination with each other, become significant when high `+RTS -N` and > very high `+RTS -A` values are used. > > 1. As we approach the `-M` limit, the computation of the new size for > generation 1 appears to be based on an incorrect figure for the total > size of the nursery. The `-A` value is used instead of the product of > that value with `-N`. This problem could lead to the total heap size > exceeding the `-M` limit. > > 2. Memory allocated from the operating system is freed only if the RTS > thinks that it would not be reallocated soon. The estimate for what will > be needed soon is based on fewer inputs than the actual resizing logic, > and in particular it is not affected by `-M`. Thus it might keep free > mblocks in excess of the `-M` limit, based on an expected heap growth > that would be forbidden by `-M`. > > We are preparing a patch to address these issues; it will point out the > particular lines of code. New description: We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We prepared to address these issues; it points out the particular lines of code: https://phabricator.haskell.org/D3143 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 22:28:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 22:28:48 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries In-Reply-To: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> References: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> Message-ID: <061.5adea1488459ad9053e5cf0fc6c9e8ac@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Description changed by j6carey: Old description: > We observed high resident set size well in excess of the `+RTS -M` limit > in a long-running, high data-volume Haskell application that Awake > Networks is deploying on a network appliance. > > We think that the current `GC.c` code has two bugs that, at least in > combination with each other, become significant when high `+RTS -N` and > very high `+RTS -A` values are used. > > 1. As we approach the `-M` limit, the computation of the new size for > generation 1 appears to be based on an incorrect figure for the total > size of the nursery. The `-A` value is used instead of the product of > that value with `-N`. This problem could lead to the total heap size > exceeding the `-M` limit. > > 2. Memory allocated from the operating system is freed only if the RTS > thinks that it would not be reallocated soon. The estimate for what will > be needed soon is based on fewer inputs than the actual resizing logic, > and in particular it is not affected by `-M`. Thus it might keep free > mblocks in excess of the `-M` limit, based on an expected heap growth > that would be forbidden by `-M`. > > We prepared to address these issues; it points out the particular lines > of code: https://phabricator.haskell.org/D3143 New description: We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We prepared a fix to address these issues; it points out the particular lines of code: https://phabricator.haskell.org/D3143 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 16 23:32:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Feb 2017 23:32:58 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.721542bf40da61790c39164d7e4af666@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I fixed a small bug in the new one-shot stuff, in this patch {{{ commit fc9d152b058f21ab03986ea722d0c94688b9969f Author: Simon Peyton Jones < simonpj at microsoft.com > Date: Thu Feb 16 09:41:55 2017 +0000 Comments and tiny refactor only }}} Here's the critical bit {{{ --- a/compiler/simplCore/OccurAnal.hs +++ b/compiler/simplCore/OccurAnal.hs @@ -1867,17 +1867,17 @@ occAnalApp env (Var fun, args, ticks) -- This is the *whole point* of the isRhsEnv predicate -- See Note [Arguments of let-bound constructors] - n_val_args = valArgCount args + length (takeWhile isOneShotInfo (occ_one_shots env)) - -- See Note [Sources of one-shot information], bullet point A' - + n_val_args = valArgCount args n_args = length args fun_uds = mkOneOcc env fun (n_val_args > 0) n_args is_exp = isExpandableApp fun n_val_args -- See Note [CONLIKE pragma] in BasicTypes -- The definition of is_exp should match that in Simplify.prepareRhs - one_shots = argsOneShots (idStrictness fun) n_val_args - -- See Note [Sources of one-shot information] + one_shots = argsOneShots (idStrictness fun) guaranteed_val_args + guaranteed_val_args = n_val_args + length (takeWhile isOneShotInfo + (occ_one_shots env)) + -- See Note [Sources of one-shot information], bullet point A'] }}} Notice that `guaranteed_val_args` should be used only for the call to `argOneShots`, not in the calls to `isExpandableApp` or `mkOneOcc`. I thoght this was just cleanup. For example, `is_exp` only matters if `isRhsEnv` is true; and in that case I think `occ_one_shots` is empty (see `rhsCtxt`); so I doubt the change to `is_exp` makes any difference at all. Nevertheless it does: we observed a 7% reduction in allocation for `haddock.base` and `haddock.Cabal` after this one patch. Bonkers! I have no idea why. But I'm just recording it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 03:21:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 03:21:53 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.b0f3260b0eaf68c535e4ff27bb75a834@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 04:39:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 04:39:49 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.ef04224d560f262f423e0bdf2952a944@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by juhpetersen): Thanks! Sorry I missed the comments. Well I have sphinx there: it is generating the User Guide html: but maybe my config is wrong somehow. I will try to dig deeper later and work out why the manpage doesn't get built for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 08:25:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 08:25:30 -0000 Subject: [GHC] #13236: Improve floating for join points In-Reply-To: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> References: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> Message-ID: <061.d5de7f5de199364368dbd3e5fc529146@haskell.org> #13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Question 2: I'm not saying that we never have a candidate MFE that has a join point as a free var. I AM saying that in that situation we should not float the MFE. How could it possibly be beneficial? Floating is mainly to get things outside a value lambda -- but that's invalid there's a free join point. Or to top level; ditto. Case closed. Can you give an example where let-binding an MFE (as a join point of course) with a free variable is beneficial? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 10:45:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 10:45:41 -0000 Subject: [GHC] #13289: Terrible loss of optimisation in presence of ticks Message-ID: <046.a52cdffdf54b8734a47f5857beb2785f@haskell.org> #13289: Terrible loss of optimisation in presence of ticks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Profiling | 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 {{{ case (error "blah") of BIG }}} You'd expect that to simplify to `error "blah"`, or more precisely to `case error "blah" of {}`. And usually it does. But if there are ticks around it, it does not, and we retain {{{ case (tick x (error "blah")) of BIG }}} The problem is in `Simpify.simplTick`. It calls `splitCont` which implements semantics I do not understand. The Right Thing is surely this. * Always push the tick onto the continuation {{{ simplTick env tickish expr cont = simplExprF env expr (mkTickIt tickish cont) }}} * Implement a suitable `mkTickIt` that pushes a tick past a continuation where possible. For example I think {{{ mkTickIt t (ApplyTo arg cont) = ApplyTo arg (mkTickIt t cont) }}} That is `(tick t e) a` becomes `tick t (e a)`. It's probably conditioned on what sort of tick, but that's fine. * The comments from `7bb0447d` (simonmar) say {{{ -- XXX: we cannot do this, because the simplifier assumes that -- the context can be pushed into a case with a single branch. e.g. -- scc case expensive of p -> e -- becomes -- case expensive of p -> scc e -- -- So I'm disabling this for now. It just means we will do more }}} But that's wrong. All we need to do is to ensure that `prepareCaseCont` always stops at the kind of tick we don't want to push inside. * Finally, the bottom case of `rebuildCall` should retain ticks from the continuation. Not too hard, but requires understanding of the semantics of ticks, which I do not have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 13:55:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 13:55:51 -0000 Subject: [GHC] #13202: Levity polymorphism panic in GHCi In-Reply-To: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> References: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> Message-ID: <061.99f8af8f20b319e65b4e30caac948d0d@haskell.org> #13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I've just seen this as well, in a different context: {{{ GHCi, version 8.1.20170217: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Records Prelude GHC.Records> :set -XTypeApplications -XDataKinds Prelude GHC.Records> let foo = getField @"name" ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170217 for x86_64-unknown-linux): isUnliftedType forall (a :: TYPE q). a :: TYPE q Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1197:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1201:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1889:10 in ghc:Type isUnliftedType, called at compiler/typecheck/TcRnDriver.hs:1822:32 in ghc:TcRnDriver 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 Fri Feb 17 13:58:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 13:58:08 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.aab27cc6c15742e80a269414202306c2@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I can't quite tell from the discussion whether you are already aware of this, but just in case: The gains in Haddock performance from "Comments and tiny refactor only" (https://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b9969f) seem to be undoing the losses of "Improve the Occurrence Analyzer’s handling of one-shot functions" (https://perf.haskell.org/ghc/#revision/a1980ecb5626ec85fc14fbd217e2d16c7d50a120). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 14:07:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 14:07:54 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.fa43b1bdcd3ac739b6de53fdde1724b5@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3144 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * failure: GHC rejects valid program => Documentation bug * differential: => Phab:D3144 Comment: I've included a comment in my documentation updates for the recent changes to overloaded labels. The unboxed tuples docs already mention that `(#` is a single lexeme. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 14:08:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 14:08:11 -0000 Subject: [GHC] #12243: RebindableSyntax and OverloadedLabels In-Reply-To: <048.6e564fb4c32d0e67f5680b5b6de4225b@haskell.org> References: <048.6e564fb4c32d0e67f5680b5b6de4225b@haskell.org> Message-ID: <063.cbdf25e28e33c23e826d5991d3eff67e@haskell.org> #12243: RebindableSyntax and OverloadedLabels -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: adamgundry Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | overloadedrecflds/should_run/T12243 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2708 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 14:08:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 14:08:32 -0000 Subject: [GHC] #13132: Compilation fails with a panic: get_op runContT In-Reply-To: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> References: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> Message-ID: <062.5c99d5707628063503de3cc085bd2a9a@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_compile/T13132, | overloadedrecflds/should_fail/T13132_duplicaterecflds Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985, Wiki Page: | Phab:D3126 -------------------------------------+------------------------------------- Changes (by adamgundry): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 14:10:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 14:10:04 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.405c3410209c17d0b3355b3a10b8708c@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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 RyanGlScott): * cc: simonpj (added) Comment: FWIW, in the example in comment:1, the loop happens upon the first call to `solveWantedsAndDrop` [http://git.haskell.org/ghc.git/blob/0e7601749d53d59df528ede996d8b54352051498:/compiler/typecheck/TcDerivInfer.hs#l645 here]. I'm a bit clueless as to where to begin searching for a place to debug this. Simon, do you have any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 15:14:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 15:14:12 -0000 Subject: [GHC] #13227: Loss of full laziness in mapFB In-Reply-To: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> References: <046.9b8e35ce6c85cbadde21d300e5829b51@haskell.org> Message-ID: <061.fd4035e1ccc92ea2629537bf994f62db@haskell.org> #13227: Loss of full laziness in mapFB -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK that's good! I still don't know ''why'' the effect is so large; but there was a definite bug, now fixed by the "tiny refactor". Which was not as tiny as I thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 15:16:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 15:16:52 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.6bdee42596eb599340872fe5dcf759d2@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): You should at least run the GC once if you want to return memory to the OS, it doesn't happen magically. If I add a `rts_performMajorGC` after `print "done"` then the stable heap usage of the program reduces to about 110MB. I think it's more or less attributable to the actual 20MB heap usage plus ghc's conservatism in returning memory to the OS (since it will likely just need it again later). I'm not sure where the 20MB leak is coming from, it's apparently a list of `FastString`s but that doesn't narrow it down very much... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 15:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 15:22:00 -0000 Subject: [GHC] #13290: Data constructors should not have RULES Message-ID: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- GHC has never (knowingly) supported rules for data constructors, like {{{ {-# RULES "BadBadBad" Just [x,y] = Just [] #-} Notice that the rule is for the ''constructor itself''. Presumably the intent is that any occurrence of `Just` appplied to a two-element list will rewrite to `Just []`. But currently they are accidentally allowed through, and then behave in mysterious ways because of constructor wrappers. Duncan Coutts says {{{ > Well I've certainly tried to use that in the past. > A previous version of the cbor lib which used a different > representation did a lot of matching on constructors to re-arrange > input to an interpreter, until I discovered that GHC actually uses > constructor wrappers and that matching on constructors was thus not > reliable }}} I think we should simply make it illegal for now. If you really want it, use a smart constructor thus {{{ mkJust x = Just x {-# INLINE [0] mkJust #-} {-# RULES “Good” mkJust [x,y] = mkJust [] #-} }}} So let us * Check in that you don't try to write a rule for a data constructor. * Document in the user manual -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 15:22:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 15:22:21 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.454dd188228fe259c3d9df2d0e1ad602@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => dfeuer Comment: David might you do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 15:36:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 15:36:59 -0000 Subject: [GHC] #13236: Improve floating for join points In-Reply-To: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> References: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> Message-ID: <061.acff34fa0b3ce4056e2871d7fea1629e@haskell.org> #13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Question 3. Here's a concrete example {{{ f b x = let j1 :: Integer -> Integer j1 y = let j2 z = if b && z>0 then z+z+z+z+z else j2 (z-1) in j2 y in if b then j1 x else j1 (x-1) }}} Currently `j2` does not float out of `j1`. I agree that it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:18:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:18:04 -0000 Subject: [GHC] #13286: Late floating of join points In-Reply-To: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> References: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> Message-ID: <061.db10320d541d86104bb4059d1bcd9209@haskell.org> #13286: Late floating of join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another: `perf/should_run/MethSharing` improves if you do float to top level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:21:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:21:50 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.e21e9ea4804b17d562e061ff273936cd@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I can give it a go, sure. But with your fix for matching strict constructors, is there any reason to prohibit it aside from the as-yet- undecided static data optimization? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:28:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:28:54 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.17b80af2c4f2aa76bb56896f7360d7f6@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > GHC has never (knowingly) supported rules for data constructors, like > {{{ > {-# RULES > "BadBadBad" Just [x,y] = Just [] > #-} > Notice that the rule is for the ''constructor itself''. Presumably the > intent is that any occurrence of `Just` appplied to a two-element list > will rewrite to `Just []`. > > But currently they are accidentally allowed through, and then behave in > mysterious ways because of constructor wrappers. Duncan Coutts says > {{{ > > Well I've certainly tried to use that in the past. > > A previous version of the cbor lib which used a different > > representation did a lot of matching on constructors to re-arrange > > input to an interpreter, until I discovered that GHC actually uses > > constructor wrappers and that matching on constructors was thus not > > reliable > }}} > I think we should simply make it illegal for now. If you really want it, > use a smart constructor thus > {{{ > mkJust x = Just x > {-# INLINE [0] mkJust #-} > {-# RULES “Good” mkJust [x,y] = mkJust [] #-} > }}} > So let us > > * Check in that you don't try to write a rule for a data constructor. > * Document in the user manual New description: GHC has never (knowingly) supported rules for data constructors, like {{{ {-# RULES "BadBadBad" Just [x,y] = Just [] #-} }}} Notice that the rule is for the ''constructor itself''. Presumably the intent is that any occurrence of `Just` appplied to a two-element list will rewrite to `Just []`. But currently they are accidentally allowed through, and then behave in mysterious ways because of constructor wrappers. Duncan Coutts says {{{ > Well I've certainly tried to use that in the past. > A previous version of the cbor lib which used a different > representation did a lot of matching on constructors to re-arrange > input to an interpreter, until I discovered that GHC actually uses > constructor wrappers and that matching on constructors was thus not > reliable }}} I think we should simply make it illegal for now. If you really want it, use a smart constructor thus {{{ mkJust x = Just x {-# INLINE [0] mkJust #-} {-# RULES “Good” mkJust [x,y] = mkJust [] #-} }}} So let us * Check in that you don't try to write a rule for a data constructor. * Document in the user manual -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:30:03 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.4e4ec27ee729b398e2a735c237e3eae4@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > But with your fix for matching strict constructors, is there any reason to prohibit it aside from the as-yet-undecided static data optimization? I don't know and I don't even want to think about it until we have a powerful reason for wanting it. It feel Wrong Wrong Wrong for a passive data constructor to start rewriting itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:35:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:35:47 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.6d141f52741d83d8a6ca48bf96f58be8@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7398 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #7398 Comment: #7398 is related (in that we can close it too if we do this). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:36:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:36:18 -0000 Subject: [GHC] #7398: RULES don't apply to a newtype constructor In-Reply-To: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> References: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> Message-ID: <061.4e877bd9dd123c30fb4ec959a3fa8cd8@haskell.org> #7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418, | Differential Rev(s): #13290 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #6082, #10418 => #6082, #10418, #13290 Comment: #13290 proposes disallowing rules for constructors altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:52:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:52:03 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.04100c8e814bc8f0c0f2c174aa3f2392@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.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 AndreasK): The issue was slightly more complicated than expected. * The runtime parses arguments correctly and ignores RTS flags past `--` * On linux `getArgs` fetches the arguments from the runtime and returns these as expected. * On Windows `getArgs` ignores the arguments provided by the RTS and instead uses `GetCommandLineW` to get the arguments, parsing these and throwing out any RTS flags without parsing them. The issue is that the code throwing out RTS flags didn't consider the case of `--` resulting in the above behavior. I see two ways to fix this: * Update the parsing code in base (easy). * Use getCommandLineW and consorts instead of argv in the RTS on Windows. (A more proper fix). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:54:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:54:24 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.d40102cc0c940715362990bbd9265957@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.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 rwbarton): Let's do the first, easy thing for 8.2 (soon). Then the more proper fix as time permits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 16:56:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 16:56:41 -0000 Subject: [GHC] #13291: bpk15 and bkp47 fail with -dunique-increment=-1 Message-ID: <046.072eb2c6046f70c3a9b73399e10e4979@haskell.org> #13291: bpk15 and bkp47 fail with -dunique-increment=-1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) 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: #4012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens on master. Repro command: {{{ cd testsuite/; make EXTRA_HC_OPTS='-dunique-increment=-1' TEST="bkp15 bkp47" }}} Result: {{{ Compile failed (exit code 1) errors were: [1 of 3] Processing p [1 of 1] Compiling A[sig] ( p/A.hsig, nothing ) [2 of 3] Processing q [1 of 1] Compiling A[sig] ( q/A.hsig, nothing ) [3 of 3] Processing r [1 of 2] Compiling A[sig] ( r/A.hsig, nothing ) bkp47.bkp:10:9: error: • Class ‘C’ has conflicting definitions in the module and its hsig file Main module: class C a where g :: a -> a f :: a -> a {-# MINIMAL f | g #-} Hsig file: class C a where f :: a -> a g :: a -> a {-# MINIMAL f #-} The methods do not match: The names ‘f’ and ‘g’ are different The names ‘g’ and ‘f’ are different • while merging the signatures from: • p[A=]:A • q[A=]:A • ...and the local signature for A bkp47.bkp:10:9: error: • Class ‘C’ has conflicting definitions in the module and its hsig file Main module: class C a where g :: a -> a f :: a -> a {-# MINIMAL f | g #-} Hsig file: class C a where f :: a -> a g :: a -> a {-# MINIMAL g #-} The methods do not match: The names ‘f’ and ‘g’ are different The names ‘g’ and ‘f’ are different • while merging the signatures from: • p[A=]:A • q[A=]:A • ...and the local signature for A }}} {{{ Compile failed (exit code 1) errors were: bkp15.bkp:1:26: warning: -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. [1 of 5] Processing p [1 of 1] Compiling H[sig] ( p/H.hsig, nothing ) [2 of 5] Processing q [1 of 1] Compiling H[sig] ( q/H.hsig, nothing ) [3 of 5] Processing r [1 of 2] Compiling H[sig] ( r/H.hsig, nothing ) bkp15.bkp:36:9: error: • Class ‘Bloop’ has conflicting definitions in the module and its hsig file Main module: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool {-# MINIMAL xa | y | xa | y #-} Hsig file: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering {-# MINIMAL xa | y #-} The methods do not match: The names ‘xa’ and ‘y’ are different The types of ‘xa’ are different The default methods associated with ‘xa’ are not compatible The names ‘y’ and ‘xa’ are different The types of ‘y’ are different The default methods associated with ‘y’ are not compatible • while merging the signatures from: • p[H=]:H • q[H=]:H • ...and the local signature for H bkp15.bkp:36:9: error: • Class ‘Bloop’ has conflicting definitions in the module and its hsig file Main module: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool {-# MINIMAL xa | y | xa | y #-} Hsig file: class GHC.Classes.Eq a => Bloop a b | a -> b where data family GMap a (v :: * -> *) xa :: a -> a -> GHC.Types.Bool default xa :: a -> a -> GHC.Types.Bool y :: a -> a -> GHC.Types.Ordering default y :: GHC.Classes.Ord a => a -> a -> GHC.Types.Ordering {-# MINIMAL xa | y #-} The methods do not match: The names ‘xa’ and ‘y’ are different The types of ‘xa’ are different The default methods associated with ‘xa’ are not compatible The names ‘y’ and ‘xa’ are different The types of ‘y’ are different The default methods associated with ‘y’ are not compatible • while merging the signatures from: • p[H=]:H • q[H=]:H • ...and the local signature for H }}} This indicates some dependence on Unique ordering. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 17:00:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 17:00:36 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.24853e456e4b31752e557405b94c1175@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7398 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): For what it's worth the documentation implicitly disallows these rules already, as it says > The left hand side of a rule must consist of a top-level variable applied to arbitrary expressions. and "variable" is used in the Haskell Report to refer to lowercase things, not constructors. Of course explicit is better than implicit, and probably the author of that sentence was not thinking about the case of constructors at the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 17:29:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 17:29:51 -0000 Subject: [GHC] #13292: panic! (the 'impossible' happened): corePrepPgm Message-ID: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> #13292: panic! (the 'impossible' happened): corePrepPgm --------------------------------------+--------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- It doesn't seem like a serious problem, but I report it anyway. With stack's project template, I just removed `main` and `someFunc`'s type signature and changed `someFunc`'s definition to `return ()`. `stack build` worked well, but `stack repl` emitted this error message. {{{ D:\ghc-corePrepPgm\app\Main.hs:6:1: warning: [-Wdeferred-type-errors] • Couldn't match type ‘ghc-prim-0.5.0.0:GHC.Prim.Any’ with ‘IO’ Expected type: IO () Actual type: ghc-prim-0.5.0.0:GHC.Prim.Any () • In the expression: main When checking the type of the IO action ‘main’ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): corePrepPgm [False] cobox_r1bo = typeError @ 'VoidRep @ (Any :: (* -> *)) ~# (IO :: (* -> *)) "D:\\ghc-corePrepPgm\\app\\Main.hs:6:1: error:\n\ \ \\226\\128\\162 Couldn't match type \\226\\128\\152ghc-prim-0.5.0.0:GHC.Prim.Any\\226\\128\\153 with \\226\\128\\152IO\\226\\128\\153\n\ \ Expected type: IO ()\n\ \ Actual type: ghc- prim-0.5.0.0:GHC.Prim.Any ()\n\ \ \\226\\128\\162 In the expression: main\n\ \ When checking the type of the IO action \\226\\128\\152main\\226\\128\\153\n\ \(deferred type error)"# 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 Fri Feb 17 17:30:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 17:30:11 -0000 Subject: [GHC] #13292: panic! (the 'impossible' happened): corePrepPgm In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.70ee68015bf6f511cb15e9712a7900b6@haskell.org> #13292: panic! (the 'impossible' happened): corePrepPgm ---------------------------------+-------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by jeiea): * Attachment "ghc-corePrepPgm.7z" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 19:38:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 19:38:37 -0000 Subject: [GHC] #13114: UniqSet definition seems shady In-Reply-To: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> References: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> Message-ID: <060.097e20b09fc9d260fe61d883812940c1@haskell.org> #13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: low | Milestone: 8.4.1 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): Phab:D3146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3146 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 20:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 20:42:34 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.44e3f3f8b87abc1b124b18c3232ee370@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7398 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I’d just like to chime in that from a user point of view, it feels very much right and natural that I can define rules that match on constructors, and I am honestly surprised that this has not been a supported use-case right from the beginning. Here is an example: {{{#!hs data FreeMonad a = Return a | Bind (FreeMonad a) (a -> FreeMonad b) {-# RULES "monadLaw1" forall x f . Bind (Return x) f = f x #-} }}} Looks very benign to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 21:10:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 21:10:19 -0000 Subject: [GHC] #13291: bpk15 and bkp47 fail with -dunique-increment=-1 In-Reply-To: <046.072eb2c6046f70c3a9b73399e10e4979@haskell.org> References: <046.072eb2c6046f70c3a9b73399e10e4979@haskell.org> Message-ID: <061.a2f182994e9ec4bf3955dcdf19aba566@haskell.org> #13291: bpk15 and bkp47 fail with -dunique-increment=-1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) 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: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Drat! Should be an easy fix though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 22:00:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 22:00:05 -0000 Subject: [GHC] #13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail Message-ID: <049.ea3bedcb6a8539f520ac94d42c50d590@haskell.org> #13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example: {{{ {-# language GeneralizedNewtypeDeriving #-} {-# language ConstrainedClassMethods #-} instance ToDoc Int where toDoc = undefined newtype P = P Int deriving ( ToDoc ) type Doc = () class ToDoc a where toDoc :: ToDoc a => a -> Doc }}} compile with ghc-8.0.2: {{{ C.hs:6:30: error: • Couldn't match type ‘Int’ with ‘P’ arising from the coercion of the method ‘toDoc’ from type ‘ToDoc Int => Int -> Doc’ to type ‘ToDoc P => P -> Doc’ • When deriving the instance for (ToDoc P) }}} With ghc-8.0.1, it is fine. When I drop the constraint on the method declaration, ghc-8.0.2 compiles the program. This repetition of the class constraint in the method declaration actually came from a copy-paste error, so this issue does not affect my code, but it's still puzzling. Repeating the class constraint should not change the meaning of the program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 22:10:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 22:10:19 -0000 Subject: [GHC] #13291: bpk15 and bkp47 fail with -dunique-increment=-1 In-Reply-To: <046.072eb2c6046f70c3a9b73399e10e4979@haskell.org> References: <046.072eb2c6046f70c3a9b73399e10e4979@haskell.org> Message-ID: <061.8a6714546462b79918119e60594f74e2@haskell.org> #13291: bpk15 and bkp47 fail with -dunique-increment=-1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) 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: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): It looks like the old class-matching code for hs-boot files assumes that methods inside a Class are always sorted (a comment suggests that they are), but it doesn't seem to be the case. It kind of looks like I'll just have to rewrite that segment of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 22:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 22:13:24 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.bedefc02f6f2274405b09794e910a2c6@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T13287 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3147 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * testcase: => T13287 * differential: => Phab:D3147 Comment: I implemented the simple fix together with a testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 22:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 22:31:38 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.dc49d2e3ba6a8878f62b78ea2dc9858d@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I'm not convinced the complexity is worth it. I think at least for GHC 8.2 we ought not to put in any of this, and we'll see if the role problems really cause people problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 17 23:48:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Feb 2017 23:48:40 -0000 Subject: [GHC] #13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail In-Reply-To: <049.ea3bedcb6a8539f520ac94d42c50d590@haskell.org> References: <049.ea3bedcb6a8539f520ac94d42c50d590@haskell.org> Message-ID: <064.d9395667d3f8262f19804f45509f07e6@haskell.org> #13293: ConstrainedClassMethods makes GeneralizedNewtypeDeriving fail -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.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 rwbarton): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #12768; see there for much discussion. The short version is: while it would arguably be correct to be able to use GND in this particular case of a class with a method which is constrained by the same class, it's not useful enough to add special logic to GHC to handle it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 01:06:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 01:06:30 -0000 Subject: [GHC] Trac email verification for user: praduca Message-ID: <20170218010630.6FDAC3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: praduca Verification Token: 4D_eeaAv -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 01:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 01:18:16 -0000 Subject: [GHC] #13294: compactResize is a terrible primop and a terrible name Message-ID: <045.dae6d915b6b6656cda9997bbc39b708a@haskell.org> #13294: compactResize is a terrible primop and a terrible name -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.1 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: -------------------------------------+------------------------------------- compactResize does two things: it changes the default block allocation size of a compact region, and appends a new block to the compact region. There are two problems with this function: first, it's terribly named; it doesn't actually do any resizing of the existing compact region to speak of. Second, there arguably isn't any reason why it should append a new block to the compact region; just let that happen automatically! But I'm not actually using compact regions for anything real. Simon Marlow, do you know why you moved compactResize from Data.Compact.Internal to Data.Compact? If there is some functionality in it that is useful for end users we should articulate it properly. I'm happy to do the docfixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 01:18:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 01:18:32 -0000 Subject: [GHC] #13294: compactResize is a terrible primop and a terrible name In-Reply-To: <045.dae6d915b6b6656cda9997bbc39b708a@haskell.org> References: <045.dae6d915b6b6656cda9997bbc39b708a@haskell.org> Message-ID: <060.906e9322d46a54eac589f3587f3974eb@haskell.org> #13294: compactResize is a terrible primop and a terrible name -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.06f6b28fb59b6a522111f4e165e494d3@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | 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 Ben Gamari ): In [changeset:"b207b536ded40156f9adb168565ca78e1eef2c74/ghc" b207b53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b207b536ded40156f9adb168565ca78e1eef2c74" Generalize kind of the (->) tycon This is generalizes the kind of `(->)`, as discussed in #11714. This involves a few things, * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep` binders, ```lang=haskell (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). a -> b -> * ``` * Unsaturated applications of `(->)` are expressed as explicit `TyConApp`s * Saturated applications of `(->)` are expressed as `FunTy` as they are currently * Saturated applications of `(->)` are expressed by a new `FunCo` constructor in coercions * `splitTyConApp` needs to ensure that `FunTy`s are split to a `TyConApp` of `(->)` with the appropriate `RuntimeRep` arguments * Teach CoreLint to check that all saturated applications of `(->)` are represented with `FunTy` At the moment I assume that `Constraint ~ *`, which is an annoying source of complexity. This will be simplified once D3023 is resolved. Also, this introduces two known regressions, `tcfail181`, `T10403` ===================== Only shows the instance, instance Monad ((->) r) -- Defined in ‘GHC.Base’ in its error message when -fprint-potential-instances is used. This is because its instance head now mentions 'LiftedRep which is not in scope. I'm not entirely sure of the right way to fix this so I'm just accepting the new output for now. T5963 (Typeable) ================ T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its fingerprint without the RuntimeRep variables that (->) expects. This will be fixed with the merge of D2010. Haddock performance =================== The `haddock.base` and `haddock.Cabal` tests regress in allocations by about 20%. This certainly hurts, but it's also not entirely unexpected: the size of every function type grows with this patch and Haddock has a lot of functions in its heap. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -0000 Subject: [GHC] #12409: Unboxed tuples have no type representations In-Reply-To: <046.32a785a6183ec0ab7732a4ef59760aa4@haskell.org> References: <046.32a785a6183ec0ab7732a4ef59760aa4@haskell.org> Message-ID: <061.640189fd6fb0396a25472bb9dfe89a0a@haskell.org> #12409: Unboxed tuples have no type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11722 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497/ghc" 8fa4bf9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497" Type-indexed Typeable This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -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.424dc2a8559adf4660fffb4445a7dfb5@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497/ghc" 8fa4bf9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497" Type-indexed Typeable This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.3cec6245d72c161a81dcb9b86366adfc@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13261 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497/ghc" 8fa4bf9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497" Type-indexed Typeable This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.3dac492aa6c2091a87981fc68381e113@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13261 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"42ff5d97b486d50b0d10e474f47e86822bb71ace/ghc" 42ff5d97/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42ff5d97b486d50b0d10e474f47e86822bb71ace" Disable Typeable binding generation for unboxed sums These things are simply too expensive to generate at the moment. More work is needed here; see #13276 and #13261. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.3f762cf7479802ff1eff4e4d7aa38e79@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497/ghc" 8fa4bf9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497" Type-indexed Typeable This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.28684995e05dcca7b7019d9355e264ca@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"42ff5d97b486d50b0d10e474f47e86822bb71ace/ghc" 42ff5d97/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42ff5d97b486d50b0d10e474f47e86822bb71ace" Disable Typeable binding generation for unboxed sums These things are simply too expensive to generate at the moment. More work is needed here; see #13276 and #13261. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:10:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:10:43 -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.1d7a45cf42a130747eda50b4c300ce93@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Typeable 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, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497/ghc" 8fa4bf9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497" Type-indexed Typeable This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 05:56:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 05:56:12 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.9fae9930f44ee1856bcd4b1e12a900e9@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 06:00:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 06:00:34 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.b2cff3581ddd48020af9a589e5a7ea39@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13261 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 08:17:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 08:17:55 -0000 Subject: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files In-Reply-To: <047.8d1466267df270460e4c08bc0ebdb93c@haskell.org> References: <047.8d1466267df270460e4c08bc0ebdb93c@haskell.org> Message-ID: <062.eb46cb5ae9dcc9746114792dd1c86bd9@haskell.org> #797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3030 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * differential: => Phab:D3030 * resolution: => fixed * milestone: 6.6 => 8.4.1 Old description: New description: Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b {{{ This allows nofib to run on Windows using `msys`. Also deprecates the old `cygwin` stuff. Test Plan: make clean && make Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3030 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 08:18:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 08:18:48 -0000 Subject: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files In-Reply-To: <047.8d1466267df270460e4c08bc0ebdb93c@haskell.org> References: <047.8d1466267df270460e4c08bc0ebdb93c@haskell.org> Message-ID: <062.7ba5aa8deb08f14b973ffc1e173389dc@haskell.org> #797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3030 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b {{{ This allows nofib to run on Windows using `msys`. Also deprecates the old `cygwin` stuff. Test Plan: make clean && make Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3030 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 10:11:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 10:11:50 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. (was: panic! (the 'impossible' happened): corePrepPgm) In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.d06deb15fe21d86b8d300570a12ea305@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: bgamari (added) * failure: None/Unknown => Other * component: Compiler => Compiler (Type checker) * os: Windows => Unknown/Multiple Comment: Hi, Thanks for the report. I am not sure that this is a bug or at least not a new one. It seems more like a limitation of the type inferencing. The confusing error message comes from the handling of packages in the `cabal` file. The error simplified is: {{{ $ ~/ghc/inplace/bin/ghc-stage2.exe Main.hs [1 of 2] Compiling Lib ( Lib.hs, Lib.o ) Lib.hs:6:12: error: * Ambiguous type variable `m0' arising from a use of `return' prevents the constraint `(Monad m0)' from being solved. Relevant bindings include someFunc :: m0 () (bound at Lib.hs:6:1) Probable fix: use a type annotation to specify what `m0' should be. These potential instances exist: instance Monad IO -- Defined in `GHC.Base' instance Monad Maybe -- Defined in `GHC.Base' instance Monad ((->) r) -- Defined in `GHC.Base' ...plus two others (use -fprint-potential-instances to see them all) * In the expression: return () In an equation for `someFunc': someFunc = return () | 6 | someFunc = return () | ^^^^^^^^^ }}} Essentially (I think) because there's so little context for the type inference it can't disambiguate between the possible types `someFunc` can have. So it can't chose which type is the most general type for `someFunc` simply because they're all valid and can be the most general type. So it needs to be told, either by adding a type signature, or using `someFunc` in a way that allows it to determine what the most general type should be. e.g. {{{ module Lib ( someFunc ) where -- someFunc :: Monad m => m () someFunc = moreFunc moreFunc :: IO () moreFunc = someFunc }}} But I'm not that familiar with GHC's typechecker so I'll reclassify and leave it for someone more knowledgeable in this area. I also don't know why `stack repl` would have worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 10:41:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 10:41:29 -0000 Subject: [GHC] #13261: Consider moving Typeable evidence generation wholly back to solver In-Reply-To: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> References: <046.685e8ca3fd9e281b5f233ed343274466@haskell.org> Message-ID: <061.f94b2d8ac00c34fcddacbcd9963c00cb@haskell.org> #13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12276 | 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 Feb 18 10:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 10:42:46 -0000 Subject: [GHC] #13276: Unboxed sums are not Typeable In-Reply-To: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> References: <046.4162392a9dfa8c9df65b438ac9c9523d@haskell.org> Message-ID: <061.d0c917d50d0b7d6200ff0b573762c787@haskell.org> #13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13261 | 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 Feb 18 11:43:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 11:43:41 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.1c73854655a41f5bc1ee74d9e352aefd@haskell.org> #149: missed CSE opportunity --------------------------------------------+------------------------------ Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | --------------------------------------------+------------------------------ Changes (by AndreasK): * Attachment "CriterionBenchFixed2.hs" added. Updated test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 13:08:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 13:08:26 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.c802bd420cf877b7a486fc09536e3ff1@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The issue isn't the warning/error, it's the fact that GHC panicked afterward. It would be helpful to have steps to reproduce that don't involve stack. E.g. `stack repl` is presumably invoking ghci somehow, what command exactly does it run? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 13:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 13:16:43 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows In-Reply-To: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> References: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> Message-ID: <065.29bce5efc92c663c7ef25ca6c17b9b84@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3154 Wiki Page: | Phab:D3155 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3154 Phab:D3155 * milestone: => 8.4.1 Comment: That'll do it. {{{ $ echo main | ../inplace/bin/ghc-stage2.exe ../Terminfo.hs -L/mingw64/lib/ -lncurses --interactive -fforce-recomp GHCi, version 8.1.20170214: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ..\Terminfo.hs, interpreted ) Ok, modules loaded: Main. *Main> *** Exception: setupTerm: Couldn't look up terminfo entry "xterm" *Main> Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 13:16:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 13:16:57 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows In-Reply-To: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> References: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> Message-ID: <065.f5bf58ea5904f3198d3a47d8efeaa455@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3154 Wiki Page: | Phab:D3155 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 13:26:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 13:26:26 -0000 Subject: [GHC] #13113: Runtime linker errors with CSFML on Windows In-Reply-To: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> References: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> Message-ID: <065.da8731a65d8d6bcc130e0316bcda7be7@haskell.org> #13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13093 | Differential Rev(s): ​Phab:D3028 Wiki Page: | Phab:D3026 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => ​Phab:D3028 Phab:D3026 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 13:55:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 13:55:53 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.3401bbc0e554b5533aac4204268c1839@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: => Phab:D3026 Phab:D3027 Phab:D3082 Phab:D3028 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 15:05:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 15:05:05 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.481a5b64e6f73bb6f3b68dcde677d339@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeiea): This is the command which causes the panic. {{{ ghc --interactive -i -isrc -hide-all-packages -package-id=base-4.9.1.0 -- in ghci :add Lib app/Main.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 15:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 15:18:28 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.0e0cde2c665caf8aae047b7ac9aa4c34@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Thanks. `-fdefer-type-errors` is also needed to reproduce (presumably you have this set in a `.ghci` file). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 15:52:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 15:52:08 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.068d9306a6f71075d8afdc5ac7f26ccb@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Oh sorry, I completely missed the panic! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 15:52:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 15:52:34 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.2092ec2c0ab44e7b616c5ed703a84f54@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: bgamari (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 17:58:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 17:58:10 -0000 Subject: [GHC] #13295: Failure to resolve type parameter determined by type family Message-ID: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> #13295: Failure to resolve type parameter determined by type family -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Proxy -- Defined to get the type forall x . 'D x data D where D :: a -> D type family F t :: D -- Will try to create values of this type through the type family -- F, i.e. G (F t) data G (d :: D) where G :: G ('D x) -- This is rejected because the type variable x in 'D x is ambiguous. -- But is it really? If there's an instance of F t then x is determined. introG :: Proxy t -> G (F t) introG _ = G -- introG is well-typed if we add an equality constraint. -- Can GHC not figure this out without our help? introG' :: forall t x . ( F t ~ 'D x ) => Proxy t -> G (F t) introG' _ = G }}} Here's the type error: {{{ • Couldn't match type ‘F t’ with ‘'D x0’ Expected type: G (F t) Actual type: G ('D x0) The type variable ‘x0’ is ambiguous • In the expression: G In an equation for ‘introG’: introG _ = G }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 18:45:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 18:45:43 -0000 Subject: [GHC] #13296: stat() calls can block Haskell runtime Message-ID: <042.f957a412d3d44b27155966b76103fe42@haskell.org> #13296: stat() calls can block Haskell runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | 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: -------------------------------------+------------------------------------- `getFileStatus` (`stat()` syscall) is marked as `unsafe`, which means that if I have e.g. `+RTS -N4`, I can't stat more than 4 files at the same time without completely stopping the Haskell world. This is an issue on network file systems, where a single `stat()` can easily take 2 milliseconds, so you typically want to do them in parallel (but due to the above you can't). The underlying problem is that there are some Linux syscalls you typically need on networked file systems that have no asynchronous equivalent; according to http://blog.libtorrent.org/2012/10/asynchronous-disk-io/ these are at least: * `stat()` * `open()` * `fallocate()` * `rename()` A quick skim through `libraries/base/System/Posix/Internals.hs` reveals the situation: * `stat()` only exists as `unsafe` * `open()` has both `safe` and `unsafe` variants (I haven't checked which one is used in practice) The remaining ones are in the `unix` package * `fallocate()` is `safe` * `rename()` is `unsafe` It seems to me that there are two issues here: 1) None of these calls should be `unsafe` because they may block for a very long time (e.g. > 0.5 ms even on the fastest LANs). 2) We need to answer the question: If we marked them as `safe`, how many of them would the RTS execute in parallel? To my current knowledge (thanks `rwbarton` and `slyfox` on #ghc), there's a pool of Haskell executing threads (the usual `-RTS -N`), and a pool of FFI threads. Are there any restrictions on the size of that latter pool? The docs https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi- chap.html#foreign-imports-and-multi-threading are not specific on that topic, simply mentioning "but there may be an arbitrary number of foreign calls in progress at any one time, regardless of the +RTS -N value". Does that mean the amount of FFI threads is truly unbounded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 19:14:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 19:14:32 -0000 Subject: [GHC] #13296: stat() calls can block Haskell runtime In-Reply-To: <042.f957a412d3d44b27155966b76103fe42@haskell.org> References: <042.f957a412d3d44b27155966b76103fe42@haskell.org> Message-ID: <057.38eaac1b70347109c3298ceb449baed3@haskell.org> #13296: stat() calls can block Haskell runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): `slyfox` on IRC answers question (2): * slyfox: yeah, ghc's RTS does not limit amount of outstanding safe FFIs. example: http://dpaste.com/2YT058D * slyfox: `ghc --make a.hs -threaded -debug && time ./a +RTS -Ds` this runs in 6 seconds and nicely prints full list of blocked threads on FFI I've also put this into a gist and confirmed it on my GHC 8.0.2: https://gist.github.com/nh2/bcf583721213d34e9f464558a91a682e Further discussion: * rwbarton: stat() in a loop in C costs about 300ns per stat call here * nh2: much easier to program than building HTTP wrappers around all software, and basic * useful features * rwbarton: so 100ns for safe call overhead is kind of significant * nh2: slyfox: I guess asking for a better API is thinking ahead a bit too much when there * isn't even an async syscall interface for it in Linux yet * rwbarton: I think that is the API slyfox means * rwbarton: getFileStatus costs another 300 ns in userspace * rwbarton: so it would be about 100 ns more on top of 600 ns * nh2: rwbarton: that is a fair point, but it is hard to get completely right: on a local FS with a fast backend (e.g. ramdisk, SSD or FS metadata in the buffer cache), stat will be very fast, but if you are on a spinning disk on a part of FS metadata that's not currently cached, a NFS, or a network-mounted VM image (e.g. Amazon EBS and the various * equivalents), it'll be 1000x slower. And there's no way to tell on which you are -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 22:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 22:02:43 -0000 Subject: [GHC] Trac email verification for user: blaze Message-ID: <20170218220243.2C0493A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: blaze Verification Token: sU7Movb5 -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 18 22:11:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Feb 2017 22:11:49 -0000 Subject: [GHC] #13297: Panic when deriving Applicative instance through transformer Message-ID: <044.ce9ad252cf611c9a6841f34706cbd1b5@haskell.org> #13297: Panic when deriving Applicative instance through transformer -------------------------------------+------------------------------------- Reporter: blaze | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if code below is valid, but panic is wrong anyway. {{{#!hs {-# Language TypeFamilies, StandaloneDeriving, GeneralizedNewtypeDeriving, UndecidableInstances #-} module Example where newtype N p m a = N (((CT p) m) a) deriving instance (CT p ~ f, Functor (f m)) => Functor (N p m) deriving instance (CT p ~ f, Applicative (f m)) => Applicative (N p m) -- panic when this line added class C p where type CT p :: (* -> *) -> * -> * }}} Compiler output for 8.0.1 and 8.0.2 is slightly different: {{{ test.hs:6:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: f1_auk[sk] }}} {{{ test.hs:6:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: f1_aun[sk] }}} If I try to derive only Functor instance, code compiles just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 00:54:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 00:54:14 -0000 Subject: [GHC] #13298: Compact API design improvements Message-ID: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> #13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 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: -------------------------------------+------------------------------------- I took a look at the compact API today and I realized that there are a lot of improvements we should make to it: 1. `fmap getCompact . compact` is a pretty common thing to do, if you don't actually care about the compact pointer. We should make a helper function for this. 2. The `SerializedCompact` data structure needs a bunch of instances. Especially, a user who wants to serialize the compact region needs to save this metadata somewhere, but we don't offer any help for doing this. 3. `importCompact` will always print a message to stderr saying pointer fixup is happening. Need to be able to suppress this message. 4. The serialization API is really unsafe; we should make it more safe by default by including some sort of fingerprint, at least. 5. There should be a convenience function for serializing to and from a file, and serializing to and from a handle. RDMA is always going to be delicate business (so keep the old API around) but for these cases we should pave the cowpaths. Here is some sample code that might help: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Environment (getArgs) import qualified Data.Set as Set import System.IO import Data.Compact import Data.Compact.Serialized import Foreign.Ptr import Foreign.Storable import Foreign.Marshal.Alloc import Control.Monad main = do [dict_file, out_file] <- getArgs dict <- readFileLatin1 dict_file c <- compact (Set.fromList (words dict)) withBinaryFile out_file WriteMode $ \h -> withSerializedCompact c $ \sc -> do -- Write out the metadata header hPutStorable h (serializedCompactRoot sc) forM_ (serializedCompactBlockList sc) $ \(ptr, l) -> do hPutStorable h ptr hPutStorable h l hPutStorable h nullPtr -- Write out the payload forM_ (serializedCompactBlockList sc) $ \(ptr, l) -> hPutBuf h ptr (fromIntegral l) mb_r <- withBinaryFile out_file ReadMode $ \h -> do -- Read out the metadata header root <- hGetStorable h let go h xs = do ptr <- hGetStorable h if ptr == nullPtr then return (reverse xs) else do l <- hGetStorable h go h ((ptr, l):xs) blocks <- go h [] let sc = SerializedCompact { serializedCompactBlockList = blocks, serializedCompactRoot = root } -- Read the payload into memory importCompact sc $ \ptr l -> void $ hGetBuf h ptr (fromIntegral l) print (fmap getCompact mb_r == Just (getCompact c)) hPutStorable :: forall a. Storable a => Handle -> a -> IO () hPutStorable h a = alloca $ \ptr -> do poke ptr a hPutBuf h ptr (sizeOf (undefined :: a)) hGetStorable :: forall a. Storable a => Handle -> IO a hGetStorable h = alloca $ \ptr -> do hGetBuf h ptr (sizeOf (undefined :: a)) peek ptr readFileLatin1 f = do h <- openFile f ReadMode hSetEncoding h latin1 hGetContents h }}} I'm happy to do these but I want to make sure I'm not stepping on FB's toes, also I don't know if bgamari wants to take patches along these lines so late in the release cycle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 01:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 01:08:27 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.68a190d7ec384f035e79fe60587f2c84@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) 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): If this gets implement, please consider default associated patterns {{{#!hs class HasZero n where pattern Zero :: n default pattern Zero :: (Num n, Eq n) => n pattern Zero = 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 02:51:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 02:51:58 -0000 Subject: [GHC] #13298: Compact API design improvements In-Reply-To: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> References: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> Message-ID: <060.dceec11c73b77ffee27188930f6bf7f9@haskell.org> #13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/compact | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I also have a [[https://github.com/bgamari/compact- serialize/blob/master/src/Data/Compact/Serialize.hs|library]] which does roughly this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 04:20:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 04:20:58 -0000 Subject: [GHC] #13299: Typecheck multiple modules at the same time Message-ID: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> #13299: Typecheck multiple modules at the same time -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- angerman asked me to outline how one might go about fixing #1409 (mutually recursive modules without hs-boot). Here is the most recent plan based on #10681 and discussion with SPJ. **The general approach.** Traditionally, users write hs-boot files, which compile to hi-boot files that are subsequently used for compilation. The approach that SPJ and I would like to take is to replace this step with a new one that generates hi-boot files from hs files. Everything else otherwise stays the same. **More details.** Let's suppose we have A.hs and B.hs which import each other, A imports B using a `SOURCE` import, but no B.hs-boot is defined. We ask GHC to typecheck A.hs and B.hs together to produce hi-boot files for each of the modules. To implement this, we need both a new major mode for this operation (similar to `ghc -c`); and GhcMake needs to be adjusted to call this step on every SCC in the import graph, when one or more modules in the import graph do not have an hs-boot file. This part of the implementation is a bit annoying and was what thwarted me when I've made some stabs at this issue in the past. Probably the easiest thing to do initially is to fix up GhcMake to call your new frontend (you'll put it in `HscMain`) on every SCC. An easy way to check progress here is to get `ghc --make` to print out SCCs before it starts compiling them. GHC needs to learn how to typecheck multiple modules at the same time. Let's talk a little bit about how typechecking works today: by the time we are at `HscMain` we generally have a `ModSummary` per source module to be compiled. You pass the ModSummary to something like `tcRnModule` and you get back out a `TcGblEnv` containing the results of typechecking. Look at `hscIncrementalCompile`: if you're compiling a module proper, we desugar and optimize it properly (`finish`) and then create an interface for it; if we're only typechecking (`finishTypecheckOnly`) we go straight to generating the interface file after checking. All of these functions assume, of course, that only one module is being typechecked at a time. So you must break this assumption. This comes in multiple steps. First, the actual typechecking, `tcRnModule` needs to be adjusted. Notice `tcRnModule` takes a single `HsParsedModule`; now you need to feed it multiple parsed modules. You probably want a new function for this? What should this function look like? Trace further into `initTc`: notice that the `TcGblEnv` structure assumes that there is only one module being compiled at a time `tcg_mod` (and other modules). So this assumption needs to be broken. Now, trace into the main body of typechecking `tcRnModuleTcRnM`. Normally the way we go about doing things is we rename imports, and then we rename and typecheck declarations. Clearly each of your parsed modules needs to have their imports resolved separately; furthermore, they might import each other. This needs to be made to work. I think this will have to be totally reimplemented, because you are going to have to deal with cases like: {{{ module A(T) where import B(T) module B(T) where import A(T) }}} This is obviously nonsense and your algorithm needs to identify this and kill it. Once you've done this you should have a separate `tcg_rdr_env` for each of the parsed modules. `tcRnImports` sets up a pile of other variables in `TcGblEnv` too (see bottom) and I'm not sure what should be done with those. Now we need to rename and typecheck the top-level declarations. Renaming of imported entities should proceed straightforwardly because you set up the GlobalRdrEnv correctly, but you need to give the correct module to each of the top-level declarations. Maybe assume no Template Haskell for now because I have no idea how that's supposed to work. The crux of the matter, though, is that once you've renamed all of the declarations, you now need to compute SCCs over ALL of the modules, because how else are you going to typecheck two mutually recursive declarations over two modules. At this point the one-module assumption of TcGblEnv shouldn't be a problem anymore because when we're dealing with renamed source everything knows its name. There's a little bit more about the export list (`tcRnExports`) but you've probably already handled this to handle the recursive imports correctly. Finally, what you'll get out in the end is a big pile of types from DIFFERENT modules `tcg_type_env` (and all of the other things: instances, etc. Though, I guess if an instance is defined in one module of a recursive module loop, it should be in scope everywhere?!) So now in the final stage, serializing to interface files, we need to disentangle everything and put the declarations for each module into a separate interface file per module. Maybe best to have kept them separate to begin with. To conclude, adding support for typechecking multiple modules at once will probably involve rewriting large swathes of the renamer and top-level typechecking driver, but everything past that should basically be unchanged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 07:32:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 07:32:44 -0000 Subject: [GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W Message-ID: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> #13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code causes the compiler to panic {{{ #!haskell {-# LANGUAGE GADTs #-} data W where WI :: Int WD :: Double data Superblock = A { f :: W } | B { f :: W } }}} {{{ [1 of 1] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/hdf5/hdf5-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon W Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package hdf5-0.1.0.0 using: /home/siddhu/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.2.0-ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build exe:hdf5 --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 11:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 11:36:16 -0000 Subject: [GHC] #13301: GHC base directory assumptions Message-ID: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> #13301: GHC base directory assumptions ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- GHC and ghc-pkg make some pretty hard assumptions about where they're running on Windows. They assume that they are always running from `foo/bin/ghc.exe` and that to find the `lib` folder they can drop `bin/ghc.exe` from the base path and append `lib`. This is already false for the testsuite, which when testing the bindist has one test which puts the binaries in `inplace/test spaces`. For some reason before this was either being skipped or mysteriously passing. But as of `2017.02.11` our luck ran out. the testsuite triggers a failure such as: {{{ [04:16:21][Step 3/6] ghc-pkg.exe: Can't find package database in C:/TeamCity/buildAgent/work/28754042a1be6052/inplace/test sp\lib [04:16:22][Step 3/6] ghc-pkg.exe: Can't find package database in C:/TeamCity/buildAgent/work/28754042a1be6052/inplace/test sp\lib [04:16:23][Step 3/6] Traceback (most recent call last): [04:16:23][Step 3/6] File "../../driver/runtests.py", line 215, in [04:16:23][Step 3/6] pkginfo = str(getStdout([config.ghc_pkg, 'dump'])) [04:16:23][Step 3/6] File "/c/TeamCity/buildAgent/work/28754042a1be6052/testsuite/driver/testutil.py", line 23, in getStdout [04:16:23][Step 3/6] raise Exception("Command failed: " + str(cmd_and_args)) [04:16:23][Step 3/6] Exception: Command failed: ['"/c/TeamCity/buildAgent/work/28754042a1be6052/inplace/test spaces/ghc- pkg.exe"', 'dump'] [04:16:23][Step 3/6] make: *** [../../mk/test.mk:299: test] Error 1 [04:16:23][Step 3/6] [04:16:23][Step 3/6] ==== STAGE 1 TESTS ==== [04:16:23][Step 3/6] cat: testsuite_summary_stage1.txt: No such file or directory [04:16:23][Step 3/6] Process exited with code 1 }}} Let's soften the assumption and just check that `../lib` exists instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 13:12:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 13:12:18 -0000 Subject: [GHC] #13301: GHC base directory assumptions In-Reply-To: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> References: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> Message-ID: <059.150a63590b3d2fd1d237507020b7b038@haskell.org> #13301: GHC base directory assumptions ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3158 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * differential: => Phab:D3158 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 13:12:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 13:12:33 -0000 Subject: [GHC] #13301: GHC base directory assumptions In-Reply-To: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> References: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> Message-ID: <059.5c21bc2183ff3952413efb7922270425@haskell.org> #13301: GHC base directory assumptions ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3158 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 13:56:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 13:56:55 -0000 Subject: [GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W In-Reply-To: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> References: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> Message-ID: <066.a416f87b566a00de09113380ff69848a@haskell.org> #13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): For those like me who failed to spot the error immediately, the correct error message is (from 7.10) {{{ W.hs:4:3: Data constructor ‘WI’ returns type ‘Int’ instead of an instance of its parent type ‘W’ In the definition of data constructor ‘WI’ In the data declaration for ‘W’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 14:54:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 14:54:56 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.35344c5694a094147b13c2310e14f149@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by Nolan): * Attachment "Lexer.x.patch" added. patch to ./compiler/parser/Lexer.x -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 15:10:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 15:10:58 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.5150a136b902aa1d288a674828cded74@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 Nolan): I'm new to ghc and this is my first ticket. Patch above dosn't work as expected. I changed rule for negative floating point literals so that it triggers(as I believe) only on non zero literals. Having that this shouldn't change default(without -XNegativeLiterals) behaviour of lexer for such cases. But for some reason it doesn't work. Non zero literals look to be correct as well as positive zero but negative zero produces such error. I don't know what it means and can't find source of this error. Searching though whole project for those messages and function it didn't help. What can it be? {{{ nolan at NolanPC:~/ghc$ ./inplace/bin/ghc-stage2 -XNegativeLiterals -e "-0.0" :0:1: error: • Non type-variable argument in the constraint: Num (a -> b) (Use FlexibleContexts to permit this) • When checking the inferred type it :: forall b c a. (Num (a -> b), Num (b -> c)) => a -> c }}} Maybe I get this wrong and this trick will not work. Do you have any ideas of how this feature should be implemented? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 15:57:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 15:57:34 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.541323570e4fbebfeec87f1fc00ae143@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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): It must be lexing `-0.0` as `-0 . 0` (which is then interpreted as an application of `(.)`), not `- 0.0`. The same logic should also apply to `-0`, since someone could write `-0 :: Double`. I suspect fixing that would also fix your problem here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 16:19:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 16:19:18 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.cdef7ad901bb3ebc4873cbd4f9f589db@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 Nolan): Yeah, I got it and probably fixed. I'm testing changes now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 18:39:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 18:39:25 -0000 Subject: [GHC] Trac email verification for user: sukhmel Message-ID: <20170219183925.614DC3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: sukhmel Verification Token: UdTLQgli -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 19:16:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 19:16:12 -0000 Subject: [GHC] #13251: Must perform family consistency check on non-imported identifiers In-Reply-To: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> References: <045.11fe7a021f96674185b51d4fd9f26c02@haskell.org> Message-ID: <060.ef6b0efafc6421bbe519ec5bd79ff64c@haskell.org> #13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies 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): GHCi lets you use a fully-qualified name to refer to an identifier without importing it (similar to TH), so I suppose we ought to treat a module used in this way as an instance provider, as well. Example from slyfox, involving an orphan instance. {{{ ghci -ignore-package=regex-tdfa-rc GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/slyfox/.ghci Prelude C TP CM> "a" Text.Regex.TDFA.=~ "^(a)|(a)$" ::[[ String ]] :1:1: error: • No instance for (Text.Regex.Base.RegexLike.RegexMaker Text.Regex.TDFA.Common.Regex Text.Regex.TDFA.Common.CompOption Text.Regex.TDFA.Common.ExecOption [Char]) arising from a use of ‘Text.Regex.TDFA.=~’ • In the expression: "a" Text.Regex.TDFA.=~ "^(a)|(a)$" :: [[String]] In an equation for ‘it’: it = "a" Text.Regex.TDFA.=~ "^(a)|(a)$" :: [[String]] Prelude C TP CM> :m Text.Regex.TDFA Prelude Text.Regex.TDFA> "a" Text.Regex.TDFA.=~ "^(a)|(a)$" ::[[ String ]] [["a","a",""]] }}} (Actually, we could in principle decide freely whether or not to provide the instances here in the sense of making them visible; but we definitely have to do the family instance consistency checks.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 19:21:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 19:21:56 -0000 Subject: [GHC] #13302: Let in do-notation with braces does not parse Message-ID: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> #13302: Let in do-notation with braces does not parse -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: do-notation, | Operating System: MacOS X let, parse | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the the syntax at https://www.haskell.org/onlinereport/haskell2010/haskellch10.html the following do-notation should parse: {{{#!hs do {let x = 4; print x} }}} But it doesn't. {{{#!hs do {let x = 4 in print x} }}} parses OK. Doesn't look like a new bug, I tried with GHC 7.8 and same result. Googling "haskell do {let ds; es} = let ds in do {es}" also shows quite a lot of people taught Haskell that way, so maybe it once worked? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 19:48:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 19:48:32 -0000 Subject: [GHC] #13302: Let in do-notation with braces does not parse In-Reply-To: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> References: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> Message-ID: <057.5bd5f6f1bc63db150bdf5154c078fd37@haskell.org> #13302: Let in do-notation with braces does not parse -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: do-notation, | let, parse Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I believe GHC is correct here. The non-layout syntax you have in mind is of course {{{ do {let {x = 4}; print x} }}} In your first snippet there is no `{` after `let`, so layout comes into play. It seems that you expect the layout rule to insert a `}` before the `;`, presumably thanks to the rule > {{{ > L (t : ts) (m : ms) = } : (L (t : ts) ms) if m ∕= 0 and parse- error(t) > }}} > Note 5. > The side condition parse-error(t) is to be interpreted as follows: if the tokens generated so far by L together with the next token t represent an invalid prefix of the Haskell grammar, and the tokens generated so far by L followed by the token “}” represent a valid prefix of the Haskell grammar, then parse-error(t) is true. But, even as much as {{{ do {let {x = 4; print x }}} is a valid prefix of the Haskell grammar, since it could continue, for example, {{{ = 5}; print x} }}} So the effect of layout does not turn your first snippet into a valid Haskell program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 20:32:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 20:32:56 -0000 Subject: [GHC] #13302: Let in do-notation with braces does not parse In-Reply-To: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> References: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> Message-ID: <057.e8213430d8cc645e83f4a686701b403a@haskell.org> #13302: Let in do-notation with braces does not parse -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: do-notation, | let, parse Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rem): You are right, I over looked the syntax rule decls → { decl_1 ; … ; decl_n } (n ≥ 0). Closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 20:34:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 20:34:42 -0000 Subject: [GHC] #13302: Let in do-notation with braces does not parse In-Reply-To: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> References: <042.3a4f86d394450a2b01e0bd9b8a24cbe1@haskell.org> Message-ID: <057.9bbf57298712176fe2091280efaf037f@haskell.org> #13302: Let in do-notation with braces does not parse -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: do-notation, | let, parse Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rem): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 19 22:05:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Feb 2017 22:05:20 -0000 Subject: [GHC] #13303: Bad pretty printer for let bindings in a do-notation with braces Message-ID: <042.e080fe04fc1e1e44e9b0fd2414738f8f@haskell.org> #13303: Bad pretty printer for let bindings in a do-notation with braces -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: do-notation, | Operating System: Unknown/Multiple let, parse | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let bindings in do-notations with braces like this: {{{#!hs module Thing where thing = do {let {x = 1}; print x} }}} get pretty printed with the braces around the bindings stripped, like this: {{{#!hs module Thing where thing = do {let x = 1; print x} }}} Steps to reproduce: copy the module into Try.hs then call: ghc -ddump-rn Try.hs I traced the code to: https://github.com/ghc/ghc/blob/e28fbbb7c3d5904a88b4743d0d10f212d61d8293/compiler/hsSyn/HsExpr.hs#L1929 which points to the pretty printer for list of declarations: https://github.com/ghc/ghc/blob/95dc6dc070deac733d4a4a63a93e606a2e772a67/compiler/hsSyn/HsBinds.hs#L492 Indeed there is a comment on the two ways to pretty print binders - without braces in multiple lines and with braces in one line. However the comment does not explain the choice, and as discussed in #13302 the former won't parse in a do-notation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 03:50:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 03:50:00 -0000 Subject: [GHC] #13295: Failure to resolve type parameter determined by type family In-Reply-To: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> References: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> Message-ID: <063.cddf7f6f6bb8a01f9fc502988435220a@haskell.org> #13295: Failure to resolve type parameter determined by type family -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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 goldfire): The error is poor (ambiguity isn't really the issue), but I agree that GHC should reject your first function but accept your second. Your first function relies critically on the fact that `D` has but one constructor. Thus, we know that an element of `D` is constructed with `'D`. Without this knowledge, then `introG` really is problematic. Although we believe it's sound to do so, GHC does not currently do this kind of reasoning (i.e., eta-expansion). In `introG'`, the type signature tells us that `F t` evaluates to a use of `'D`, so the missing piece is provided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 04:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 04:30:12 -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.4cb8f8091c1c23f880058836c5d5eefb@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.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: | Phab:D1795 -------------------------------------+------------------------------------- Comment (by rwbarton): It's very strange. I also see `OptCoercion` taking several minutes and gobs of memory to compile, when I copy it somewhere and build it with `-package ghc`; but according to my logs from investigating join points it never takes particularly long to compile as part of the ghc build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 07:16:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 07:16:41 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.493335c0b3bc0a9f4adcebf07eaa351a@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): == mandel and gcd The main difference seems to come from [https://github.com/takano- akio/ghc/commit/1edc47406dd2f5da9925978b01a1724028bd576e this change], which makes `integer-gmp` allocate less by inlining wrappers for `S#`, `Jp#` etc. Actually this small change seems to be responsible for the much of the allocation improvement in this branch: {{{ gcd +0.8% -21.4% 0.039 0.040 0.0% integer +1.1% -1.5% +5.0% +5.1% 0.0% mandel +1.1% -24.4% 0.070 0.070 0.0% -------------------------------------------------------------------------------- Min -0.0% -24.4% -38.7% -38.5% 0.0% Max +1.1% 0.0% +13.7% +13.6% +14.4% Geometric Mean +0.3% -0.6% -6.9% -6.9% +0.1% }}} Perhaps I should try go get this change merged, separately from the rest of the nested CPR work. == Binary size increase I had a brief look at `nofib/real/fluid/Jcb_method.hs`, which showed a +60% increase in the binary size, but I wasn't able to figure out why the change happened. !SpecConstr now seems to duplicate a big function, but I don't know what caused this (yet). == Wiki page I think the content under wiki:NestedCPR is mostly valid, because all I have done so far is essentially just to rebase nomeata's branch on top of the join-point commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:18:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:18:19 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.e48a4d1131a6a3239a16158aed2decb1@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | 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): See #13293 for another example of the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:42:46 -0000 Subject: [GHC] #13295: Failure to resolve type parameter determined by type family In-Reply-To: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> References: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> Message-ID: <063.c5613d3fe97324fee9b3afd48b8cff79@haskell.org> #13295: Failure to resolve type parameter determined by type family -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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): It's not just that GHC doesn't do this kind of reasoning; it's also that system FC does not (yet, anyway) have a way to express the evidence. What you want to say is "for any type `t`, `F t` must be equal to `'D s` for some type `s`". But * If `F` has no instances that statement isn't true; `F t` isn't equal to any type other than `F t`. * Even if it does, we'd need an axiom of form {{{ forall t. F t ~ (exists s. 'D s) }}} and we have no such form. So I think this is well out of reach just at the moment. Not wrong; just out of reach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:49:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:49:57 -0000 Subject: [GHC] #13299: Typecheck multiple modules at the same time In-Reply-To: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> References: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> Message-ID: <060.65d505b199c301a908f7cb1896fb3e6b@haskell.org> #13299: Typecheck multiple modules at the same time -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The approach that SPJ and I would like to take is to replace this step with a new one that generates hi-boot files from hs files. Really? Everything that follows appears to follow a different plan: compile the modules of a mutually recursive group of modules all together, as if they were one big module. Which makes sense. I don't get the bit about generating hi-boot files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:53:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:53:09 -0000 Subject: [GHC] #13298: Compact API design improvements In-Reply-To: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> References: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> Message-ID: <060.ccf9c7acd9723a97f80dd8468902d730@haskell.org> #13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/compact | Resolution: | Keywords: Operating System: 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): Hack away. We're not using the serialization API, and I didn't put much effort into it during my recent refactoring other than to make sure it still works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:58:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:58:00 -0000 Subject: [GHC] #13299: Typecheck multiple modules at the same time In-Reply-To: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> References: <045.dfcebe14462ee09655c9aff33be2d1da@haskell.org> Message-ID: <060.70e2ed1dffec8d900c2994441a488fa3@haskell.org> #13299: Typecheck multiple modules at the same time -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > angerman asked me to outline how one might go about fixing #1409 > (mutually recursive modules without hs-boot). Here is the most recent > plan based on #10681 and discussion with SPJ. > > **The general approach.** Traditionally, users write hs-boot files, which > compile to hi-boot files that are subsequently used for compilation. The > approach that SPJ and I would like to take is to replace this step with a > new one that generates hi-boot files from hs files. Everything else > otherwise stays the same. > > **More details.** Let's suppose we have A.hs and B.hs which import each > other, A imports B using a `SOURCE` import, but no B.hs-boot is defined. > > We ask GHC to typecheck A.hs and B.hs together to produce hi-boot files > for each of the modules. To implement this, we need both a new major > mode for this operation (similar to `ghc -c`); and GhcMake needs to be > adjusted to call this step on every SCC in the import graph, when one or > more modules in the import graph do not have an hs-boot file. This part > of the implementation is a bit annoying and was what thwarted me when > I've made some stabs at this issue in the past. Probably the easiest > thing to do initially is to fix up GhcMake to call your new frontend > (you'll put it in `HscMain`) on every SCC. An easy way to check progress > here is to get `ghc --make` to print out SCCs before it starts compiling > them. > > GHC needs to learn how to typecheck multiple modules at the same time. > Let's talk a little bit about how typechecking works today: by the time > we are at `HscMain` we generally have a `ModSummary` per source module to > be compiled. You pass the ModSummary to something like `tcRnModule` and > you get back out a `TcGblEnv` containing the results of typechecking. > Look at `hscIncrementalCompile`: if you're compiling a module proper, we > desugar and optimize it properly (`finish`) and then create an interface > for it; if we're only typechecking (`finishTypecheckOnly`) we go straight > to generating the interface file after checking. > > All of these functions assume, of course, that only one module is being > typechecked at a time. So you must break this assumption. This comes in > multiple steps. First, the actual typechecking, `tcRnModule` needs to be > adjusted. Notice `tcRnModule` takes a single `HsParsedModule`; now you > need to feed it multiple parsed modules. You probably want a new function > for this? What should this function look like? Trace further into > `initTc`: notice that the `TcGblEnv` structure assumes that there is only > one module being compiled at a time `tcg_mod` (and other modules). So > this assumption needs to be broken. > > Now, trace into the main body of typechecking `tcRnModuleTcRnM`. Normally > the way we go about doing things is we rename imports, and then we rename > and typecheck declarations. Clearly each of your parsed modules needs to > have their imports resolved separately; furthermore, they might import > each other. This needs to be made to work. I think this will have to be > totally reimplemented, because you are going to have to deal with cases > like: > > {{{ > module A(T) where > import B(T) > > module B(T) where > import A(T) > }}} > > This is obviously nonsense and your algorithm needs to identify this and > kill it. Once you've done this you should have a separate `tcg_rdr_env` > for each of the parsed modules. `tcRnImports` sets up a pile of other > variables in `TcGblEnv` too (see bottom) and I'm not sure what should be > done with those. > > Now we need to rename and typecheck the top-level declarations. Renaming > of imported entities should proceed straightforwardly because you set up > the GlobalRdrEnv correctly, but you need to give the correct module to > each of the top-level declarations. Maybe assume no Template Haskell for > now because I have no idea how that's supposed to work. The crux of the > matter, though, is that once you've renamed all of the declarations, you > now need to compute SCCs over ALL of the modules, because how else are > you going to typecheck two mutually recursive declarations over two > modules. At this point the one-module assumption of TcGblEnv shouldn't be > a problem anymore because when we're dealing with renamed source > everything knows its name. > > There's a little bit more about the export list (`tcRnExports`) but > you've probably already handled this to handle the recursive imports > correctly. > > Finally, what you'll get out in the end is a big pile of types from > DIFFERENT modules `tcg_type_env` (and all of the other things: instances, > etc. Though, I guess if an instance is defined in one module of a > recursive module loop, it should be in scope everywhere?!) So now in the > final stage, serializing to interface files, we need to disentangle > everything and put the declarations for each module into a separate > interface file per module. Maybe best to have kept them separate to begin > with. > > To conclude, adding support for typechecking multiple modules at once > will probably involve rewriting large swathes of the renamer and top- > level typechecking driver, but everything past that should basically be > unchanged. New description: angerman asked me to outline how one might go about fixing #1409 (mutually recursive modules without hs-boot). Here is the most recent plan based on #10681 and discussion with SPJ. **The general approach.** Traditionally, users write hs-boot files, which compile to hi-boot files that are subsequently used for compilation. The approach that SPJ and I would like to take is to replace this step with a new one that typechecks all of the hs files at once. **More details.** Let's suppose we have A.hs and B.hs which import each other, A imports B using a `SOURCE` import, but no B.hs-boot is defined. We ask GHC to typecheck A.hs and B.hs together to produce hi-boot files for each of the modules. To implement this, we need both a new major mode for this operation (similar to `ghc -c`); and GhcMake needs to be adjusted to call this step on every SCC in the import graph, when one or more modules in the import graph do not have an hs-boot file. This part of the implementation is a bit annoying and was what thwarted me when I've made some stabs at this issue in the past. Probably the easiest thing to do initially is to fix up GhcMake to call your new frontend (you'll put it in `HscMain`) on every SCC. An easy way to check progress here is to get `ghc --make` to print out SCCs before it starts compiling them. GHC needs to learn how to typecheck multiple modules at the same time. Let's talk a little bit about how typechecking works today: by the time we are at `HscMain` we generally have a `ModSummary` per source module to be compiled. You pass the ModSummary to something like `tcRnModule` and you get back out a `TcGblEnv` containing the results of typechecking. Look at `hscIncrementalCompile`: if you're compiling a module proper, we desugar and optimize it properly (`finish`) and then create an interface for it; if we're only typechecking (`finishTypecheckOnly`) we go straight to generating the interface file after checking. All of these functions assume, of course, that only one module is being typechecked at a time. So you must break this assumption. This comes in multiple steps. First, the actual typechecking, `tcRnModule` needs to be adjusted. Notice `tcRnModule` takes a single `HsParsedModule`; now you need to feed it multiple parsed modules. You probably want a new function for this? What should this function look like? Trace further into `initTc`: notice that the `TcGblEnv` structure assumes that there is only one module being compiled at a time `tcg_mod` (and other modules). So this assumption needs to be broken. Now, trace into the main body of typechecking `tcRnModuleTcRnM`. Normally the way we go about doing things is we rename imports, and then we rename and typecheck declarations. Clearly each of your parsed modules needs to have their imports resolved separately; furthermore, they might import each other. This needs to be made to work. I think this will have to be totally reimplemented, because you are going to have to deal with cases like: {{{ module A(T) where import B(T) module B(T) where import A(T) }}} This is obviously nonsense and your algorithm needs to identify this and kill it. Once you've done this you should have a separate `tcg_rdr_env` for each of the parsed modules. `tcRnImports` sets up a pile of other variables in `TcGblEnv` too (see bottom) and I'm not sure what should be done with those. Now we need to rename and typecheck the top-level declarations. Renaming of imported entities should proceed straightforwardly because you set up the GlobalRdrEnv correctly, but you need to give the correct module to each of the top-level declarations. Maybe assume no Template Haskell for now because I have no idea how that's supposed to work. The crux of the matter, though, is that once you've renamed all of the declarations, you now need to compute SCCs over ALL of the modules, because how else are you going to typecheck two mutually recursive declarations over two modules. At this point the one-module assumption of TcGblEnv shouldn't be a problem anymore because when we're dealing with renamed source everything knows its name. There's a little bit more about the export list (`tcRnExports`) but you've probably already handled this to handle the recursive imports correctly. Finally, what you'll get out in the end is a big pile of types from DIFFERENT modules `tcg_type_env` (and all of the other things: instances, etc. Though, I guess if an instance is defined in one module of a recursive module loop, it should be in scope everywhere?!) So now in the final stage, serializing to interface files, we need to disentangle everything and put the declarations for each module into a separate interface file per module. Maybe best to have kept them separate to begin with. To conclude, adding support for typechecking multiple modules at once will probably involve rewriting large swathes of the renamer and top-level typechecking driver, but everything past that should basically be unchanged. -- Comment (by ezyang): Sorry, that sentence wasn't worded very clearly. The distinction is when we actually run the optimizer. The "obvious" thing to do is, after typechecking all of the modules in the loop together, is to optimize all of the modules together. However, an alternate strategy, that gets you more separate compilation, is to stop, emit an hi-boot file for each module you typechecked, and then do another pass compiling the modules in order (using the hi-boot interfaces to break loops, as is the case today.) The benefit of this strategy is that, while you have to retypecheck every module in the loop any time you edit any module, you don't necessarily have to recompile every module. It also saves you from having to teach the optimizer how to optimize multiple modules at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:59:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:59:16 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem Message-ID: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I have tried both 8.0.1 and 8.0.2 versions of GHC. 7.10.3 runs just fine. Installation process is also much faster for 7.10.3, later versions have taken around 4 hours to be installed. Programs compiled with slow GHC are also slow. Sample program: {{{#!haskell main = putStrLn "Hello, world!" }}} GHC is installed with Stack. Windows version is 1607 build 15031.0 I believe this could be a bug in implementation of Ubuntu subsystem, but I'm not quite sure what part of it is failing. {{{ $ time stack ghc -- -e 'putStrLn ""' real 2m28.240s user 0m0.375s sys 3m30.078s $ time stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 real 1m45.533s user 0m0.125s sys 2m46.516s time stack ghc --compiler ghc-8.0.1 -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 real 2m54.764s user 0m0.234s sys 3m58.422s }}} {{{ $ time ghc -e 'putStrLn ""' real 0m0.872s user 0m0.109s sys 0m0.125s $ time ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 real 0m0.072s user 0m0.000s sys 0m0.031s time stack ghc --compiler ghc-7.10.3 -- -e 'putStrLn ""' real 0m0.876s user 0m0.234s sys 0m0.688s time stack ghc --compiler ghc-7.10.3 -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 real 0m0.832s user 0m0.109s sys 0m0.813s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-8.0.2 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 3m56.582s user 0m0.609s sys 5m8.125s $ time ./test Hello, world! real 0m27.540s user 0m0.000s sys 0m27.297s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-7.10.3 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 0m2.222s user 0m0.406s sys 0m1.406s $ time ./test Hello, world! real 0m0.030s user 0m0.000s sys 0m0.031s }}} Part of Stack output with timings: {{{ $ stack ghc --verbose -- -e 'putStrLn "Hello, world!"' Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0 ... 2017-02-19 21:13:05.756085: [debug] No project config file found, using defaults. 2017-02-19 21:13:05.759402: [debug] Run from outside a project, using implicit global project config 2017-02-19 21:13:05.761724: [debug] Using resolver: lts-8.0 from implicit global project's config file: /home/sukhmel/.stack/global- project/stack.yaml ... 2017-02-19 21:13:05.788855: [debug] Run process: /sbin/ldconfig -p 2017-02-19 21:13:05.816489: [debug] Process finished in 26ms: /sbin/ldconfig -p 2017-02-19 21:13:05.820648: [debug] Run process: /usr/bin/gcc -v 2017-02-19 21:13:05.844975: [debug] Process finished in 23ms: /usr/bin/gcc -v ... 2017-02-19 21:13:05.854997: [debug] Using standard GHC build 2017-02-19 21:13:05.856774: [debug] Getting global package database location ... 2017-02-19 21:13:05.867711: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:13:05.888957: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version 2017-02-19 21:13:05.919968: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:13:38.605653: [debug] Process finished in 32736ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:14:11.930034: [debug] Process finished in 32792ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:14:11.931071: [debug] Process finished in 32831ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version ... 2017-02-19 21:14:11.939817: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc -e "putStrLn \"Hello, world!\"" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 08:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 08:59:49 -0000 Subject: [GHC] #13296: stat() calls can block Haskell runtime In-Reply-To: <042.f957a412d3d44b27155966b76103fe42@haskell.org> References: <042.f957a412d3d44b27155966b76103fe42@haskell.org> Message-ID: <057.6652b479b5ba882ed83a323ee0b27ea5@haskell.org> #13296: stat() calls can block Haskell runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The default implementation should be `safe`, and we could provide an internal `unsafe` version for people who know what they're doing and want that extra 100ns. Separately we should work on reducing the overhead of `safe` calls. I have an experimental patch here: https://phabricator.haskell.org/D1466 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 09:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 09:02:43 -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.0cca2012caf11f772887d676b88acf9a@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.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: | Phab:D1795 -------------------------------------+------------------------------------- Comment (by simonpj): Suggestion: switch on `-ticky` or profiling for the regular build process, to try to get an idea of where that time and space is going. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 09:19:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 09:19:25 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.c13947b39608070431ace850bde6462a@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The main difference seems to come from ​this change... Interesting! There are two changes in that commit: * Making data con wrappers have `ug_unsat_ok = unSaturatedOk`. I buy this. Can you try the effect of this change alone? It's entirely unrelated to nested-CPR. It would be good to isolate that perf bump from the perf changes due to nested CPR. * Making data con wrapper have `ug_boring_ok = boringCxtOk`. I'm not sure I buy this in full. In `Note [Inline data constructor wrappers aggresively]` there's a claim that we get better nested-CPR info. That's true if we have a polymorphic bang argument (e.g. `data T a = MkT !a`) but for a monomorphic one like `data S = MkS !Int` we'll unpack it. So I think the benefit comes only for polymorphic bangs. And there is a cost to aggressive inlining, so we don't want to do it gratuitously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 09:20:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 09:20:25 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem In-Reply-To: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> References: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> Message-ID: <061.868192475cea71ded61c7889f2b34bbd@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sukhmel): Also filed an issue to [https://github.com/Microsoft/BashOnWindows/issues/1713 BashOnWindows] issue tracker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 09:34:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 09:34:26 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem In-Reply-To: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> References: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> Message-ID: <061.d18095ab124a4f2e2f5205b34b59a32e@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I assume stack is not necessary to reproduce this? Can you post reproduction instructions without it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:04:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:04:14 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables Message-ID: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} module Main where import Data.Proxy import GHC.StaticPtr foo :: forall a. StaticPtr (Proxy a) foo = static (Proxy :: Proxy a) main :: IO () main = putStrLn "Hi" }}} This yields {{{ Only identifiers of top-level bindings can appear in the body of the static form: static (Proxy :: Proxy a) but the following identifiers were found instead: a }}} but `a` is a type-level variable and therefore by definition static. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:07:05 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions Message-ID: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been running into some difficulties with type inference for static expressions; I suspect not enough type information might be propagated down. Below are a number of tests, all of which compare type inference for `static` with type inference for a function {{{#!hs fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined }}} Apart from syntactic checks, I'd expect `static ` and `fake`Static ` to behave more or less the same, but they don't. Here are some examples: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} module Main where import Data.Proxy import Data.Typeable import GHC.StaticPtr {------------------------------------------------------------------------------- Setup -------------------------------------------------------------------------------} -- Some kind of non-injective type family type family NonInj a where NonInj Bool = () NonInj Char = () -- To compare against the real static fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined {------------------------------------------------------------------------------- Test 1: identity function -------------------------------------------------------------------------------} f1 :: Proxy a -> NonInj a -> NonInj a f1 Proxy = id f2 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) f2 Proxy = fakeStatic id -- Fails with: -- -- Couldn't match type ‘a0’ with ‘NonInj a’ -- Expected type: NonInj a -> NonInj a -- Actual type: a0 -> a0 -- The type variable ‘a0’ is ambiguous -- f3 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f3 Proxy = static id -- Fails with the same error -- f4 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f4 Proxy = (static id) :: StaticPtr (NonInj a -> NonInj a) {------------------------------------------------------------------------------- Test 2: adding some kind of universe -------------------------------------------------------------------------------} data U :: * -> * where UB :: U Bool UC :: U Char f5 :: U a -> NonInj a -> NonInj a f5 _ = id -- This works just fine f6 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f6 = static f5 -- but if we introduce Typeable .. f7 :: Typeable a => U a -> NonInj a -> NonInj a f7 _ = id -- .. fakeStatic still works f8 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f8 = fakeStatic f7 -- .. but static leads to a weird error: -- No instance for (Typeable a) arising from a use of ‘f7’ -- f9 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) -- f9 = static f7 {------------------------------------------------------------------------------- Test 3: GADT wrapping StaticPtr -------------------------------------------------------------------------------} data Static :: * -> * where StaticPtr :: StaticPtr a -> Static a StaticApp :: Static (a -> b) -> Static a -> Static b -- Serializable types can be embedded into Static; here we just support U StaticBase :: U a -> Static (U a) -- this is fine f10 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f10 x = StaticPtr (fakeStatic f5) `StaticApp` (StaticBase x) -- but this fails with -- Couldn't match type ‘NonInj a -> NonInj a’ -- with ‘NonInj a0 -> NonInj a0’ -- Expected type: U a -> NonInj a -> NonInj a -- Actual type: U a0 -> NonInj a0 -> NonInj a0 -- f11 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) -- f11 x = StaticPtr (static f5) `StaticApp` (StaticBase x) -- although in this case we can work around it with a type annotation: -- (note that for f4 above this workaround didn't work) f12 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f12 x = StaticPtr (static f5 :: StaticPtr (U a -> NonInj a -> NonInj a)) `StaticApp` (StaticBase x) {------------------------------------------------------------------------------- End of tests -------------------------------------------------------------------------------} main :: IO () main = putStrLn "Hi" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:10:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:10:54 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.f097ed336802f4eebbd3a6b68c85872e@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by edsko: Old description: > I've been running into some difficulties with type inference for static > expressions; I suspect not enough type information might be propagated > down. Below are a number of tests, all of which compare type inference > for `static` with type inference for a function > > {{{#!hs > fakeStatic :: Typeable a => a -> StaticPtr a > fakeStatic = undefined > }}} > > Apart from syntactic checks, I'd expect `static ` and `fake`Static > ` to behave more or less the same, but they don't. Here are some > examples: > > {{{#!hs > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE StaticPointers #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE GADTs #-} > > module Main where > > import Data.Proxy > import Data.Typeable > import GHC.StaticPtr > > {------------------------------------------------------------------------------- > Setup > -------------------------------------------------------------------------------} > > -- Some kind of non-injective type family > type family NonInj a where > NonInj Bool = () > NonInj Char = () > > -- To compare against the real static > fakeStatic :: Typeable a => a -> StaticPtr a > fakeStatic = undefined > > {------------------------------------------------------------------------------- > Test 1: identity function > -------------------------------------------------------------------------------} > > f1 :: Proxy a -> NonInj a -> NonInj a > f1 Proxy = id > > f2 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> > NonInj a) > f2 Proxy = fakeStatic id > > -- Fails with: > -- > -- Couldn't match type ‘a0’ with ‘NonInj a’ > -- Expected type: NonInj a -> NonInj a > -- Actual type: a0 -> a0 > -- The type variable ‘a0’ is ambiguous > -- f3 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a > -> NonInj a) > -- f3 Proxy = static id > > -- Fails with the same error > -- f4 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a > -> NonInj a) > -- f4 Proxy = (static id) :: StaticPtr (NonInj a -> NonInj a) > > {------------------------------------------------------------------------------- > Test 2: adding some kind of universe > -------------------------------------------------------------------------------} > > data U :: * -> * where > UB :: U Bool > UC :: U Char > > f5 :: U a -> NonInj a -> NonInj a > f5 _ = id > > -- This works just fine > f6 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> > NonInj a) > f6 = static f5 > > -- but if we introduce Typeable .. > f7 :: Typeable a => U a -> NonInj a -> NonInj a > f7 _ = id > > -- .. fakeStatic still works > f8 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> > NonInj a) > f8 = fakeStatic f7 > > -- .. but static leads to a weird error: > -- No instance for (Typeable a) arising from a use of ‘f7’ > -- f9 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a > -> NonInj a) > -- f9 = static f7 > > {------------------------------------------------------------------------------- > Test 3: GADT wrapping StaticPtr > -------------------------------------------------------------------------------} > > data Static :: * -> * where > StaticPtr :: StaticPtr a -> Static a > StaticApp :: Static (a -> b) -> Static a -> Static b > -- Serializable types can be embedded into Static; here we just support > U > StaticBase :: U a -> Static (U a) > > -- this is fine > f10 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static > (NonInj a -> NonInj a) > f10 x = StaticPtr (fakeStatic f5) `StaticApp` (StaticBase x) > > -- but this fails with > -- Couldn't match type ‘NonInj a -> NonInj a’ > -- with ‘NonInj a0 -> NonInj a0’ > -- Expected type: U a -> NonInj a -> NonInj a > -- Actual type: U a0 -> NonInj a0 -> NonInj a0 > -- f11 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static > (NonInj a -> NonInj a) > -- f11 x = StaticPtr (static f5) `StaticApp` (StaticBase x) > > -- although in this case we can work around it with a type annotation: > -- (note that for f4 above this workaround didn't work) > f12 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static > (NonInj a -> NonInj a) > f12 x = StaticPtr (static f5 :: StaticPtr (U a -> NonInj a -> NonInj a)) > `StaticApp` (StaticBase x) > > {------------------------------------------------------------------------------- > End of tests > -------------------------------------------------------------------------------} > > main :: IO () > main = putStrLn "Hi" > }}} New description: I've been running into some difficulties with type inference for static expressions; I suspect not enough type information might be propagated down. Below are a number of tests, all of which compare type inference for `static` with type inference for a function {{{#!hs fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined }}} Apart from syntactic checks, I'd expect `static ` and `fakeStatic ` to behave more or less the same, but they don't. Here are some examples: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} module Main where import Data.Proxy import Data.Typeable import GHC.StaticPtr {------------------------------------------------------------------------------- Setup -------------------------------------------------------------------------------} -- Some kind of non-injective type family type family NonInj a where NonInj Bool = () NonInj Char = () -- To compare against the real static fakeStatic :: Typeable a => a -> StaticPtr a fakeStatic = undefined {------------------------------------------------------------------------------- Test 1: identity function -------------------------------------------------------------------------------} f1 :: Proxy a -> NonInj a -> NonInj a f1 Proxy = id f2 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) f2 Proxy = fakeStatic id -- Fails with: -- -- Couldn't match type ‘a0’ with ‘NonInj a’ -- Expected type: NonInj a -> NonInj a -- Actual type: a0 -> a0 -- The type variable ‘a0’ is ambiguous -- f3 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f3 Proxy = static id -- Fails with the same error -- f4 :: forall a. Typeable (NonInj a) => Proxy a -> StaticPtr (NonInj a -> NonInj a) -- f4 Proxy = (static id) :: StaticPtr (NonInj a -> NonInj a) {------------------------------------------------------------------------------- Test 2: adding some kind of universe -------------------------------------------------------------------------------} data U :: * -> * where UB :: U Bool UC :: U Char f5 :: U a -> NonInj a -> NonInj a f5 _ = id -- This works just fine f6 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f6 = static f5 -- but if we introduce Typeable .. f7 :: Typeable a => U a -> NonInj a -> NonInj a f7 _ = id -- .. fakeStatic still works f8 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) f8 = fakeStatic f7 -- .. but static leads to a weird error: -- No instance for (Typeable a) arising from a use of ‘f7’ -- f9 :: (Typeable a, Typeable (NonInj a)) => StaticPtr (U a -> NonInj a -> NonInj a) -- f9 = static f7 {------------------------------------------------------------------------------- Test 3: GADT wrapping StaticPtr -------------------------------------------------------------------------------} data Static :: * -> * where StaticPtr :: StaticPtr a -> Static a StaticApp :: Static (a -> b) -> Static a -> Static b -- Serializable types can be embedded into Static; here we just support U StaticBase :: U a -> Static (U a) -- this is fine f10 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f10 x = StaticPtr (fakeStatic f5) `StaticApp` (StaticBase x) -- but this fails with -- Couldn't match type ‘NonInj a -> NonInj a’ -- with ‘NonInj a0 -> NonInj a0’ -- Expected type: U a -> NonInj a -> NonInj a -- Actual type: U a0 -> NonInj a0 -> NonInj a0 -- f11 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) -- f11 x = StaticPtr (static f5) `StaticApp` (StaticBase x) -- although in this case we can work around it with a type annotation: -- (note that for f4 above this workaround didn't work) f12 :: forall a. (Typeable a, Typeable (NonInj a)) => U a -> Static (NonInj a -> NonInj a) f12 x = StaticPtr (static f5 :: StaticPtr (U a -> NonInj a -> NonInj a)) `StaticApp` (StaticBase x) {------------------------------------------------------------------------------- End of tests -------------------------------------------------------------------------------} main :: IO () main = putStrLn "Hi" }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:35:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:35:51 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem In-Reply-To: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> References: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> Message-ID: <061.33bccc8e9716a579748cdab6b9b18f33@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sukhmel): [comment:2 mpickering], here are the steps: 1. `wget http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-deb8-linux.tar.xz` 2. `tar -xJf ghc-8.0.2-x86_64-deb8-linux.tar.xz` 3. `cd ghc-8.0.2` 4. `./configure --prefix=/tmp/ghc` 5. `make install` 6. `time /tmp/ghc/bin/ghc -e 'putStrLn ""'` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:40:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:40:17 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.99d762696a024fdd56f53ca00fac8b7a@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: mboes, facundo.dominguez (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:41:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:41:17 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported Message-ID: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following currently fails to compile: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module A ( T(T) ) where data Impl = Impl Int newtype T = MkT Impl pattern T {x} = MkT (Impl x) {-# LANGUAGE RecordWildCards #-} module B where import A foo :: T -> Int foo T{x} = x }}} As far as GHC can see, in module `B`, `T` does not have a field `x`. The fix is to manually export `x` from `A`: {{{#!hs module A (T(T, x)) where }}} But this is tedious for records with a large amount of fields -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 11:41:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 11:41:37 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.b8fa66de93e4bbc1f522d7ff1c75847e@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: mboes, facundo.dominguez (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 12:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 12:37:04 -0000 Subject: [GHC] #13308: Treat leading whitespace in rts flag arguments in a uniform way Message-ID: <047.bf1c5aff8d4bd07b8fa583c493342e06@haskell.org> #13308: Treat leading whitespace in rts flag arguments in a uniform way -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4243 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When parsing argument flags ghc treats leading whitespace different depending on the flag. * `ghc +RTS '-N 2' -s -RTS --version` Here '-N 2' is parsed as -N2 * `ghc +RTS '-s file' -RTS --version` Here '-N 2' is parsed as '\ file', a filename starting with a space. * `ghc +RTS -N 2 -s -RTS --version` Here `2` is a unexpected argument. The usage info indicates no space is allowed in between flags and arguments making the first point a minor bug. It's never an issue when executing from a shell since it filters out unquoted spaces, however it can trip someone up when passing arguments explicitly via exec. If we remove leading spaces for file names however we make it impossible to use filenames starting with whitespace since we cant tell if the space was included by accident or quoted by the shell. But I also have never seen a file starting with whitespace that was created intentionally so maybe that is a worthwhile tradeoff. If the argument Parser #4243 ever get's rewritten maybe this could be made uniform one way or the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 13:12:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 13:12:22 -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.e12e597277938a2d20a1660ff27e9fbf@haskell.org> #4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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 #13308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #9839 => #9839 #13308 Comment: When parsing arguments to flags ghc treats leading whitespace different depending on the flag. ghc +RTS '-N 2' -s -RTS --version Here '-N 2' is parsed as -N2 ghc +RTS '-s file' -RTS --version Here '-N 2' is parsed as '\ file', a filename starting with a space. If this rework ever happens leading spaces in arguments should either be uniformly ignored or treated as errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 13:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 13:13:24 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.271aa4a304e3b0e4536fcdfc37927a52@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 13:13:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 13:13:54 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.4977b790410172d74cab847c128f54ec@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T13287 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3147 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 13:20:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 13:20:50 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.845a55025ee3932105ab79ad02236dfb@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well if you had a plain old {{{ newtype T = T { x :: Impl } }}} then this would be the correct, Report-specified behavior. So I think your example is slightly wrong somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 14:45:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 14:45:17 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.d6857210c7bca695e4a37cec641bd5d7@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The error about `f9` makes sense because after dictionary translation the syntactic restriction is no longer met: {{{#!hs f9 dTa dTNIa = static (f7 dTa) }}} From `static f7` you could get a `StaticPtr (forall a. Typeable a => U a -> NonInj a -> NonInj a)`, if that were legal. But in order to get a `U a -> NonInj a -> NonInj a` you need to combine the (static) `f7` with a (not static) `Typeable` dictionary. The other errors all involve `StaticPtr (NonInj a -> NonInj a)`, with a type argument that does not determine `a`. I'm not sure whether this is okay (or useful); it feels potentially dubious, but I can't see concretely why it would be bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 14:49:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 14:49:32 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.b47b79aee4e0803565f8f609f2446050@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Ah, fair enough re `f9`, although the error message is confusing. The other errors are a simplification from real code; for _us_ it is useful at least :) Moreover, from a typing perspective, there's no reason why any of them should be rejected, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 14:53:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 14:53:57 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.66bdc527e4efb360dcd6c5549c685fb1@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > The following currently fails to compile: > > {{{#!hs > {-# LANGUAGE PatternSynonyms #-} > module A > ( T(T) > ) where > > data Impl = Impl Int > > newtype T = MkT Impl > > pattern T {x} = MkT (Impl x) > > {-# LANGUAGE RecordWildCards #-} > module B where > > import A > > foo :: T -> Int > foo T{x} = x > }}} > > As far as GHC can see, in module `B`, `T` does not have a field `x`. The > fix is to manually export `x` from `A`: > > {{{#!hs > module A (T(T, x)) where > }}} > > But this is tedious for records with a large amount of fields New description: The following currently fails to compile: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module A( T( MkT2 ) ) where data Impl = Impl Int newtype T = MkT Impl pattern MkT2 {x} = MkT (Impl x) {-# LANGUAGE RecordWildCards #-} module B where import A foo :: T -> Int foo MkT2{x} = x }}} As far as GHC can see, in module `B`, `MkT2` does not have a field `x`. The fix is to manually export `x` from `A`: {{{#!hs module A (T(MkT2, x)) where }}} But this is tedious for records with a large amount of fields -- Comment (by simonpj): Yes, with plain old `newtype T` you could say [{{ module A( T(..) ) where newtype T = MkT { x :: Impl } }}} to export both `MkT` and `x` along with `T`. But in the example ocharles wants to bundle the pattern synonym data constructor `MkT2` in with the type constructor `T`. Maybe you would like to say {{{ module A( T( MkT, MkT2(..) ) where ... }}} to mean the same as `T( MkT, MkT2, x )`. But we don't currently support that. I suppose you could say that the notation `T( MkT, MkT2, .. )` means "T together with data constructor/pattern synonyms `MkT` and `MkT2`, plus their field names. But that would be a (modest) design change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 15:03:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 15:03:45 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.c2f8627de7a985de1b0356f4b2d8082a@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): Specifically, I only want to export the type of the newtype (`T`), and the pattern synonym `MkT2`. The "real" constructor `MkT` for the newtype is internal to the module and not exported. In my actual work, `Impl` is a record with ~10 fields, and I want to have a `newtype` over `Impl` that looks like a record with 10 fields, though they will have different names (proxying to the underlying fields in `Impl`). So yes, what Simon comments with is indeed what I would like to be able to do (though I wouldn't export `MkT`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 15:04:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 15:04:57 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.1fcd61f1a6f7e41c11ef5ba069a6057d@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can you write something like {{{ module A( T, pattern MkT2(..) ) where ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 15:17:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 15:17:18 -0000 Subject: [GHC] #13072: Move large tuples to a separate module in base In-Reply-To: <047.4df951c2bddac1813610b08eef5bf762@haskell.org> References: <047.4df951c2bddac1813610b08eef5bf762@haskell.org> Message-ID: <062.815732a2e2c4de63dcaee3f6aa9a4007@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 8.2.1 => 8.4.1 Comment: This won't be done for 8.2.1 (if at all). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 15:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 15:45:48 -0000 Subject: [GHC] #13289: Terrible loss of optimisation in presence of ticks In-Reply-To: <046.a52cdffdf54b8734a47f5857beb2785f@haskell.org> References: <046.a52cdffdf54b8734a47f5857beb2785f@haskell.org> Message-ID: <061.b02b81ec8229e474d8006d933a2c4765@haskell.org> #13289: Terrible loss of optimisation in presence of ticks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 15:53:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 15:53:31 -0000 Subject: [GHC] #13309: Use liftA2 in ApplicativeDo Message-ID: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> #13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Now that `liftA2` is in `Applicative`, we want to be sure to use it when desugaring `ApplicativeDo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 15:53:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 15:53:53 -0000 Subject: [GHC] #13309: Use liftA2 in ApplicativeDo In-Reply-To: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> References: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> Message-ID: <060.a251e6a358736c108098f5ed68483d99@haskell.org> #13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 16:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 16:04:08 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem In-Reply-To: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> References: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> Message-ID: <061.a290b8ac259cb807f257ca4ef5b17871@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #9706 Comment: This is indeed a BashOnWindows bug. The original issue reported in comment:1 has been closed in favor of this one (https://github.com/Microsoft/BashOnWindows/issues/1671). In that thread, a BashOnWindows dev [https://github.com/Microsoft/BashOnWindows/issues/1671#issuecomment-277764856 notes]: > This is on our backlog but is unlikely to make the Creators Update. I know we're planning on looking at this soon though. > > For some context, I've looked at what causes this slowdown. For some reason stack has mapped an mind-bogglingly huge region of memory (I'm talking dozens of terabytes). When we fork we walk the entire address range to set up the new process's state. We have a design that should vastly speed this up, but we're approaching "pencils down" date for Creators Update. The "some reason" is #9706, which explains why this can't be reproduced in GHC 7.10. There's not much that GHC can do from its end (besides waiting for BashOnWindows to apply a fix), so I'm going to close this as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 16:44:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 16:44:28 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.2024cd99c620cfe1ccbaa9e7cc0270b5@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I would suggest adding at least two new flags to `rtsopts=`. * One to disable all parsing of RTS flags except the ones included at compile time. * One to disable parsing of RTS flags passed via arguments but still allow parsing of arguments passed via ENVs. My suggestions would be to use `ignore` and `ignoreArgs` although I'm open to suggestions. I don't see a usecase for parsing argument RTS flags but ignoring ENV Flags but that would be a logical third option. (`ignoreENV`?) Although not sure how useful parsing only env is as well since it suffers from the same problem of applying RTS flags where one might not have intended to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 16:46:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 16:46:51 -0000 Subject: [GHC] #13295: Failure to resolve type parameter determined by type family In-Reply-To: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> References: <048.831721c5435ed137cf42aa5ede0ed4ab@haskell.org> Message-ID: <063.c8612ce5a72a6415479b8668f5d32e53@haskell.org> #13295: Failure to resolve type parameter determined by type family -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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 alexvieth): I see. So the necessary theoretical work just hasn't been done. I hope that eventually `introG` can be accepted, but in the mean-time, perhaps we could come up with a more helpful error message? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 17:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 17:14:37 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.ab52b8866c1a7c4b2c6773a48224f4d5@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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): Summary of the discussion of this ticket at today's meeting: * When we type check (in `tcApplicativeStmts`) a group of independent statements {{{#!hs do pat1 <- exp1 pat2 <- exp2 ... patN <- expN }}} stuff bound by `pat1` should ''not'' be visible in `exp2`, and so on. Here stuff includes both the (visible) values bound by `pat1`, and also (invisible) dictionaries or equality constraints bound by matching on a qualified or GADT constructor. However, ''all'' the stuff (both visible and invisible) bound by any of the patterns should be in scope after the group. * We decided how to split a `do` expression into groups of independent statements earlier, in the renamer, on syntactic grounds; that is, based only on ''visible'' stuff. But there could be invisible dependencies too, such as in {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ApplicativeDo #-} module T12870 where data T a = Eq a => T f :: (Monad m) => a -> a -> m (T a) -> (Bool -> m b) -> m (b, b) f x y mta mb = do T <- mta r1 <- mb (x == y) r2 <- mb (x == y) return (r1, r2) }}} This program compiles today without `ApplicativeDo`, but causes the panic discussed here with `ApplicativeDo`. In the current scheme we determine the groups of independent statements in the renamer, which is too early to detect that the expression `mb (x == y)` relies on the binding of `T`. Plus Simon thinks it would be too fragile anyways. (What if there was another `Eq a` instance in scope from somewhere else? Which instance do we use? It would affect the grouping.) Simon's suggestion was to reject a program like this in the type checking stage. It would be a bit unfortunate, because the program would have compiled fine without `ApplicativeDo`. Here's another suggestion: whenever there is a pattern match that binds invisible stuff, just assume that that stuff is used in all following statements. Similar to "just disable ApplicativeDo for existential patterns", but the issue isn't existentials, but rather dictionaries or equality constraints. The original program using `data A = forall a. A a` is actually fine to treat as a single group of independent statements, since the pattern match on `A _` doesn't bind any invisible stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 17:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 17:31:49 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.f1e1690af5098f6795cd4d918279dec7@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:35:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:35:43 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.3dfce58a4710ed752f5acd2b6f6e3230@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): The real underlying goal here is to export `T`, `MkT2` and `x`, without having to mention `x`, or export `MkT`. mpickering and I discussed this over IRC and we converged (at least for the moment) on this sketch of a design. * Things can have associated things. Automatically associated to a type are its constructors and record fields. Automatically associated to a pattern synonym are its record fields. (And so on for classes, etc.) * The effect of association is: `Foo(..)` in an export or import list means "Foo and all the things associated to `Foo`". * You can associate a pattern synonym to a type with the `T(P)` export list form (this is the same as "bundling", and maybe I should just use the word "bundled" everywhere). (And it might be useful for other things as well; for example, if you change a class method to a top-level function, by bundling the function with the class, you can preserve the meaning of importing `C(..)`.) * Things being associated is transitive, so then the fields of the pattern synonym are associated with the type, too. This means that in particular > `T( MkT, MkT2, .. )` means "`T` together with data constructor/pattern synonyms `MkT` and `MkT2`, ''plus their field names''". However merely associating a field name `x` of `MkT` with the type `T` ''does not mean'' that exporting `( T( MkT ) )` causes `x` to be exported; because there is no `..` in `T( MkT )`. So, I think that this design is backwards compatible with the Haskell 2010 meaning of `..`. Then, the other thing that is needed is the ability to write either {{{ T( MkT2(..) ) }}} or {{{ T( MkT2 ), pattern MkT2(..) }}} in an export list (or import list) to export (or import) `MkT2` along with all of its associated things. This is already the meaning of the constructions `T(..)` and `C(..)` in Haskell 2010, so this seems like mostly a parser change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:41:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:41:47 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.e13331a2ff6af3bbb038e808cbb39b4e@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2d5be63d1140a409eb18d1a77d439053844f7ce7/ghc" 2d5be63d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d5be63d1140a409eb18d1a77d439053844f7ce7" Change -dppr-ticks to -dsuppress-ticks I spent about two hours today hunting fruitlessly for a simplifier bug (when fixing Trac #13255), only to find that it was caused by -ddump-X silently suppressing all ticks in Core. I think this has happened to me once before. So I've changed to make tick-printing on by default (like coercions, etc), with a flag -dsuppress-ticks (like -dsuppress-coercions) to suppress them. Blargh. -dppr-ticks is still there, but deprecated. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:46:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:46:20 -0000 Subject: [GHC] #12413: Compact regions support needs some discussion in the release notes In-Reply-To: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> References: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> Message-ID: <061.c18ee5c8d16c054974241ee8fbe94489@haskell.org> #12413: Compact regions support needs some discussion in the release notes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Documentation | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ezyang (added) Comment: Edward, perhaps you'd like to take care of this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:46:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:46:40 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.43da24652c89c8ab157a0d470caf7571@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Typeable, | 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 bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:47:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:47:16 -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.333bfc4c282ece54cef7afa27229f6f1@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: fixed | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: It's done (although at an unfortunately high cost to compiler performance, which I'll be working to reduce). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:47:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:47:36 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.8c5e7da34ba18303d9fdb846208b985b@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D2768 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I think we may want to bump this to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:51:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:51:17 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.2e2d04d46e8c6bfc60cc92e8c30c7313@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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 bgamari): * milestone: 8.2.1 => 8.4.1 Comment: We discussed this on the call and Simon said that fixing this correctly will be non-trivial. I'm (sadly) going to bump to 8.4 unless something changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:52:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:52:25 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.aa9865d4ff128e6a34e98c9d3f0df546@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's still a bit of a bummer that `DeriveAnyClass` has become //worse//. Perhaps we should just revert 639e702b6129f501c539b158b982ed8489e3d09c for now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:53:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:53:55 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.8ea5dccc5c59b9ecf18780cb3e230403@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Isn't it better now in other ways, though? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 18:55:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 18:55:55 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.95aded959297f7d731557b66d52c25a5@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > Isn't it better now in other ways, though? That's true. I really don't know how many pieces of code in the wild actually structure their default type signatures in a way that's analogous to the original program, so if not too many folks complain about it during the 8.2 release candidate window, I suppose we could deem 639e702b6129f501c539b158b982ed8489e3d09c a net positive and live with it for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:19:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:19:42 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.ac44ec4cb3b2af881267a6149118b6e5@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:20:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:20:51 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.6d6eff8d2e25d205b8de795293ee94a8@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.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 rwbarton): * keywords: PatternSynonyms, newcomer => PatternSynonyms * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:22:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:22:13 -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.ef96f8c969a85937853f1909d8d75f3c@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Typeable 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, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Is this done? comment:35 is a bit cryptic. If not done, could you clarify what remains? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:23:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:23:16 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.02977eeffbeae623b47d8939e16d551c@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9636 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:24:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:24:06 -0000 Subject: [GHC] #11817: Add proper support for weak symbols to the runtime linker In-Reply-To: <044.9d336eb495121fb8a216ccf15f54097a@haskell.org> References: <044.9d336eb495121fb8a216ccf15f54097a@haskell.org> Message-ID: <059.c1a3278e44607627b76762219fbd9a26@haskell.org> #11817: Add proper support for weak symbols to the runtime linker -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/linking/T3333, | rts/T11223/T11223_weak* Blocked By: | Blocking: Related Tickets: #11223, #3333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Did something happen here already? I can't remember. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:26:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:26:15 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.4d30b72749aa6bfe6c4088e8d22427f9@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:26:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:26:25 -0000 Subject: [GHC] #12389: Limit duplicate export warnings for datatypes In-Reply-To: <045.b9512948fd651abba4c3deecd83cbcfe@haskell.org> References: <045.b9512948fd651abba4c3deecd83cbcfe@haskell.org> Message-ID: <060.f1588a323af7ae9e5829726d53f0630f@haskell.org> #12389: Limit duplicate export warnings for datatypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.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: #11959 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:26:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:26:37 -0000 Subject: [GHC] #12389: Limit duplicate export warnings for datatypes In-Reply-To: <045.b9512948fd651abba4c3deecd83cbcfe@haskell.org> References: <045.b9512948fd651abba4c3deecd83cbcfe@haskell.org> Message-ID: <060.542b8257a043748e1293ee93455c7cce@haskell.org> #12389: Limit duplicate export warnings for datatypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11959 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:27:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:27:00 -0000 Subject: [GHC] #13152: Provide a mechanism to notify build system when .hi file is ready In-Reply-To: <047.38e2134538b3404b1f045ea57eb9cc2e@haskell.org> References: <047.38e2134538b3404b1f045ea57eb9cc2e@haskell.org> Message-ID: <062.88fd8b017ba09f6d42c58f249c48ecd6@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Driver | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:43:34 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.554d06b72374e3270acc48b7aae1ab56@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T13255 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * testcase: => simplCore/should_compile/T13255 * resolution: => fixed Comment: This was fixed in 5cef996c7cac724174a4f9b3ecceb4f84737d49e. About to push a commit adding the testcase from comment:9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 19:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 19:52:17 -0000 Subject: [GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem In-Reply-To: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> References: <046.fff1628c445cbdca91412338bb9063a4@haskell.org> Message-ID: <061.c2b9215cb2fe9df4d9aedcb65cbc454a@haskell.org> #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Btw, is a disabled-large-address-space build maintained on 64-bit Linux? I planned to play with WSL when Creator's Update is out, but AFAIUI we won't see the fix there, so any GHC 8+ will be unusable on it. Thus I wonder what is the current state of disabled-large-address-space configuration on 64-bit Linux? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 21:51:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 21:51:33 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.20efc017c050590121bedbb1e8868d5c@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ethercrow Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: | https://phabricator.haskell.org/D3139 -------------------------------------+------------------------------------- Changes (by ethercrow): * status: new => patch * differential: => https://phabricator.haskell.org/D3139 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 22:01:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 22:01:55 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.f8f484583479ea602872d0d9b34dbf49@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 simonpj): Generally that seems fine. But Haskell's namespace control system is more complicated than it looks -- see Iavor's [https://web.cecs.pdx.edu/~mpj/pubs/hsmods.pdf 2002 Haskell Symposium paper] -- so I would urge a careful, clear specification before any more implementation happens. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 22:47:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 22:47:30 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.c30cdae6380be91c2bcea8265dab15dd@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I thikn I have a fix actually. Wait till tomorrow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 23:06:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 23:06:31 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.3f0456077f19fe1013536624a7254172@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: simplCore/should_compile/T13255 => Comment: Unfortunately I hadn't previously noticed that the repro from comment:9 involved `Text` and `bytestring-base64`, neither of which are anywhere near being boot packages. I'm afraid it looks like adding a testcase for this one isn't currently possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 23:19:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 23:19:13 -0000 Subject: [GHC] #13310: Cut a new array release Message-ID: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> #13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The `array` package needs a new release for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 23:39:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 23:39:41 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.d408660cfe4497f1b5609e1b5270f913@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Edward says "I can't check particulars right now. I can definitely say I'd like some way to attain an equivalent result, but I accept that it may not be possible with the machinery we have." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 23:56:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 23:56:01 -0000 Subject: [GHC] #13264: GHC panic with (->) generalization branch while compiling lens In-Reply-To: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> References: <046.bb522d70988005d72d1c68ae52b24d73@haskell.org> Message-ID: <061.982fdcff207d8c8c4b6cb4c4fc287b1d@haskell.org> #13264: GHC panic with (->) generalization branch while compiling lens -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): * status: new => closed * resolution: => fixed Comment: This is fixed in the version of my patch which was merged (b207b536ded40156f9adb168565ca78e1eef2c74). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 23:56:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 23:56:58 -0000 Subject: [GHC] #13279: Check known-key lists In-Reply-To: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> References: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> Message-ID: <060.ffb5642992cfea60b88085349b7ffcda@haskell.org> #13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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): * owner: (none) => dfeuer * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 20 23:58:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Feb 2017 23:58:49 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries In-Reply-To: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> References: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> Message-ID: <061.c8dd4d8e3a19b9b9a157cd6b0c31c8c3@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3143 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 00:11:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 00:11:52 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.bade69f871e993bd939f735a718d606b@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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): Simon I have realised another problem with `ApplicativeDo`, not covered by our paper. Consider {{{ data A where A :: a -> (a->Int) -> A st :: A -> A -> IO (Int,Int) st p q = do p1 <- pure p A x1 f1 <- pure p1 q1 <- pure q A x2 f2 <- pure q1 pure (f1 x1, f2 x2) }}} We'll try to gather `(x1,f1)` in a pair, and `(x2,f2)`; but that won't work because they each mention an existential type variable. Our desugaring just doesn't work at all for that case. What to do? Another awkward wrinkle: what are the dependencies induced by view patterns? And do we account for them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 01:25:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 01:25:35 -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.80fe9fbeb8c07b213580c77a4cd48ae0@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Typeable 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, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): From the discussion I've seen, I am purely guessing that all the necessary internal ''representations'' are now available, but the solver part is not. I.e. with `PolyKinds` enabled, the definition {{{ {-# LANGUAGE PolyKinds #-} import Data.Typeable f :: Typeable a => Proxy a -> TypeRep f = typeOf }}} still won't compile, but you ''probably'' can now use the new `TypeRep` mechanisms do write an ''equivalent'' function by hand. On the other hand, since 8.0 with `TypeInType` you can write {{{ f :: (Typeable (a::k), Typeable k) => Proxy a -> TypeRep f = typeOf }}} which means the actual ''need'' for this improvement is less than it was in 7.10. At the time I wrote this ticket, I was somewhat thinking about preserving backwards compatibility, which got broken in 7.10 anyhow. (And until recent trouble with the `constraints` package, I thought no one had been affected in practice - but the last version of that package actually now restricts the kind of the `Deferrable (a ~ b)` instance to `*` in just 7.10, because of this, see discussion at end of https://github.com/ekmett/constraints/issues/43.) Incidentally in GHCi 8.0.1, with `PolyKinds` but ''not'' `TypeInType` enabled: {{{ Prelude Data.Typeable> let f x at Proxy = typeOf x Prelude Data.Typeable> :t f f :: forall k (t :: k). (Typeable * k, Typeable k t) => Proxy k t -> TypeRep }}} which is convenient, but means you get an inferred type you cannot write. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 02:44:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 02:44:00 -0000 Subject: [GHC] #13283: T5435_dyn_asm fails with gold linker In-Reply-To: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> References: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> Message-ID: <062.5e4435c31262637ad682038c2793c613@haskell.org> #13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 02:55:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 02:55:08 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.4b46fca6edb4a9073488331990cb5832@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Sadly I didn't have a chance to finish this patch for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 03:07:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 03:07:40 -0000 Subject: [GHC] #13283: T5435_dyn_asm fails with gold linker In-Reply-To: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> References: <047.36eb865c88d25a39da9d50709990bfe9@haskell.org> Message-ID: <062.5c5d897bd7cfd273c42d604ca3efc19d@haskell.org> #13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: 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): We should just make the test not fail (by sorting the output or something) and submit a report to gold. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 04:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 04:06:04 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.46c7b87020e405e75fe3965add524e7b@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.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): * owner: bgamari => (none) Comment: Well, Typeable is merged and this is still an issue. I don't have time to look at this in the near future so I'll drop it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 10:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 10:30:27 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.71830c8928e437574d9d41cb5659e805@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fd841f877ab7a991f667a50b401404927f6f599c/ghc" fd841f87/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd841f877ab7a991f667a50b401404927f6f599c" Fix DeriveAnyClass (again) This patch fixes Trac #13272. The general approach was fine, but we were simply not generating the correct implication constraint (in particular generating fresh unification variables). I added a lot more commentary to Note [Gathering and simplifying constraints for DeriveAnyClass] I'm still not very happy with the overall architecture. It feels more complicate than it should. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 10:37:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 10:37:31 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.f43eb21e0b324b2727cc9aa14c51999b@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T13272, | T13272a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_compile/T13272, T13272a * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 10:43:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 10:43:56 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.9ca0238cac1c6450bc938709a32019e1@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you sure that 5cef996c7cac724174a4f9b3ecceb4f84737d49e is merged to HEAD? I don't see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 10:44:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 10:44:04 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.85bcf2b2dc945f544e19a4f964d8050c@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: simonpj => (none) * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 11:00:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 11:00:33 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.0bd953e58a468638699bb1e7ac531601@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T13272, | T13272a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.4.1 => 8.2.1 Comment: Many thanks Simon, you're a lifesaver. For my edification, which part in particular was causing the reported error? Was it the fact that we were creating new variables in `inferConstraintsDAC` without using `pushTcLevelM`? Or was it due to not using explicit unification variables (via `newMetaTyVarsX`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 11:01:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 11:01:26 -0000 Subject: [GHC] #13272: DeriveAnyClass regression involving a rigid type variable In-Reply-To: <050.046f36ed66c175f36546939641b2ee09@haskell.org> References: <050.046f36ed66c175f36546939641b2ee09@haskell.org> Message-ID: <065.6eb4711681a290e0a73f3bf43f147b68@haskell.org> #13272: DeriveAnyClass regression involving a rigid type variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T13272, | T13272a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The latter! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 12:47:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 12:47:40 -0000 Subject: [GHC] #13202: Levity polymorphism panic in GHCi In-Reply-To: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> References: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> Message-ID: <061.4f4d1c88b8e1d8f8b7d33195e27c53b8@haskell.org> #13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 12:52:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 12:52:06 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.7eeec713e261d4f72c5adcb3f8173ce1@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Status on this: Reid/David are going to look into why so much time is going into Lint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 14:29:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 14:29:08 -0000 Subject: [GHC] #13297: Panic when deriving Applicative instance through transformer In-Reply-To: <044.ce9ad252cf611c9a6841f34706cbd1b5@haskell.org> References: <044.ce9ad252cf611c9a6841f34706cbd1b5@haskell.org> Message-ID: <059.56d5b8dc565dc77e75675813875695ae@haskell.org> #13297: Panic when deriving Applicative instance through transformer -------------------------------------+------------------------------------- Reporter: blaze | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"713ebd7cf03876c6bedc1be9fba8f60ccc5bc8f0/ghc" 713ebd7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="713ebd7cf03876c6bedc1be9fba8f60ccc5bc8f0" Fix computation of dfun_tvs in mkNewTypeEqn This bug was causing Trac #13297. We were recomputing ds_tvs, and doing it wrongly (by omitting variables that appear only in mtheta). But actually plain 'tvs' is just fine. So code deleted, and bug fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 14:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 14:31:27 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.6868d3e2e5a4406202c406ccc1cddfae@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6e3288473718fcd8e6ad15a5e7db5b7ab43e9cbb/ghc" 6e328847/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e3288473718fcd8e6ad15a5e7db5b7ab43e9cbb" Fix SetLevels for join points This fixes Trac #13255. The trouble was that we had a bottoming join point, and tried to float it to top level. But it had free JoinIds, so we tried to abstract over them. Disaster. Lint should have caught it, but didn't (now fixed). This patch fixes the original problem. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 14:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 14:31:27 -0000 Subject: [GHC] #13281: Linting join points In-Reply-To: <046.384b28181188b76e598e4ffd0bb5c6fd@haskell.org> References: <046.384b28181188b76e598e4ffd0bb5c6fd@haskell.org> Message-ID: <061.f41cd40822fafe631e656b570052a84c@haskell.org> #13281: Linting join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e790126cd57ab39649b1fd42996733fafe20eb34/ghc" e790126/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e790126cd57ab39649b1fd42996733fafe20eb34" Improve Core Lint, mainly for join points * lintSingleBinding: check that join points have a valid join-point type (Trac #13281) * lintIdBinder: check that a JoinId is bound by a non-top-level let i.e. not a top level binder not lambda/case binder * Check for empty Rec [] bindings * Rename lintIdBndrs to lintLetBndrs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 14:32:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 14:32:59 -0000 Subject: [GHC] #13255: aws package fails to build with master In-Reply-To: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> References: <046.43e5cbc3af2fdcab972007406206c4a9@haskell.org> Message-ID: <061.434fb929f7abaf9085c7ca34c7b7480d@haskell.org> #13255: aws package fails to build with master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed the commit was lost during a rebase. There we are. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 15:02:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 15:02:39 -0000 Subject: [GHC] #13297: Panic when deriving Applicative instance through transformer In-Reply-To: <044.ce9ad252cf611c9a6841f34706cbd1b5@haskell.org> References: <044.ce9ad252cf611c9a6841f34706cbd1b5@haskell.org> Message-ID: <059.33e8b51363f3b861a1c57056b4435eff@haskell.org> #13297: Panic when deriving Applicative instance through transformer -------------------------------------+------------------------------------- Reporter: blaze | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | deriving/should_compile/T13297 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => deriving/should_compile/T13297 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 15:03:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 15:03:22 -0000 Subject: [GHC] #13281: Linting join points In-Reply-To: <046.384b28181188b76e598e4ffd0bb5c6fd@haskell.org> References: <046.384b28181188b76e598e4ffd0bb5c6fd@haskell.org> Message-ID: <061.dedb3dd7998bbd51ece99149800cb713@haskell.org> #13281: Linting join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 15:06:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 15:06:49 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect In-Reply-To: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> References: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> Message-ID: <059.bcb67e6521530b014583466f4a50ec50@haskell.org> #12636: ProfHeap's printf modifiers are incorrect -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3129 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): These counts can legitimately be negative, so we should use real signed types here. Sorry I didn't notice this earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 15:27:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 15:27:16 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy Message-ID: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- When fixing #12918, I ended up needing to introduce a helper function called `tcSplitNestedSigmaTys`, which is quite similar to `tcSplitSigmaTy`, except that it attempts to look through as many nested `forall`s as possible. (See the documentation for `tcSplitNestedSigmaTys` [http://git.haskell.org/ghc.git/blob/611f998fd545b45167170d9e60b7d9147178f0a1:/compiler/typecheck/TcType.hs#l1378 here]). In the process, I accidentally discovered a bug! First, consider this program: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where class C a where op :: forall b c. (Monoid b, Monoid c, Eq a) => a -> b -> c }}} This should be (and is) rejected, since we're trying to constrain `a` with `Eq` in `op`, but we don't have `-XConstraintedClassMethods` enabled. But what about this equivalent program? {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where class C a where op :: forall b. Monoid b => forall c. Monoid c => Eq a => a -> b -> c }}} By the same logic, this should also be rejected. But in GHC 8.0.2, it wasn't! That's because we were checking for the presence of constrained class variables using `tcSplitSigmaTy`, which only gives you `Monoid b` as the constraint, totally ignoring the bogus constraint inside of `forall c. Monoid c => Eq a => a -> b -> c`. When I fixed #12918 (a seemingly unrelated task), I ended up replacing that very use of `tcSplitSigmaTy` with `tcSplitNestedSigmaTys`. Now it gives you `(Monoid b, Monoid c, Eq a)` as expected when checking the constraints, and the second program is now rightly rejected on GHC HEAD. But I fear that there may be many more bogus uses of `tcSplitSigmaTy`. I should go through and try flushing out bugs of a similar caliber, and see if subbing in `tcSplitNestedSigmaTys` fixes these bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 15:27:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 15:27:33 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.c7d42f7fcc466e0679541be75ead0e3b@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.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 RyanGlScott): * owner: (none) => RyanGlScott -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 15:56:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 15:56:45 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.b75b587a2979e6807224180a0fed8708@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.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'm not terribly bothered about failing to reject a program without `-XConstrainedClassMethods` once you start having `RankNTypes`. By all means look at it; but I'm not losing sleep over it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:01:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:01:37 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.3c06de2242cb322c0401baf4c54efe1d@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 simonmar): @simonpj One position is to say that it should typecheck if the desugaring (according to the paper) is type-correct, which in this case it isn't. And in fact I think that's what happens: {{{ do1.hs:12:8: error: • Couldn't match expected type ‘t0’ with actual type ‘(a -> Int, a)’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: A :: forall a. a -> (a -> Int) -> A, in a pattern binding in 'do' block at ado1.hs:12:3-9 • In the pattern: (f1, x1) In the expression: do { p1 <- pure p; A x1 f1 <- pure p1; q1 <- pure q; A x2 f2 <- pure q1; return (f1 x1, f2 x2) } In an equation for ‘st’: st p q = do { p1 <- pure p; A x1 f1 <- pure p1; q1 <- pure q; A x2 f2 <- pure q1; return (f1 x1, f2 x2) } • Relevant bindings include f1 :: a -> Int (bound at ado1.hs:12:8) x1 :: a (bound at ado1.hs:12:5) }}} Arguably we should do something more clever, but at least it's sound. So I'm less worried about this case than the original one which typechecks but generates invalid Core. I'll investigate to see if I can make it typecheck the rhs's separately from the patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:07:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:07:04 -0000 Subject: [GHC] Trac email verification for user: Saish Message-ID: <20170221170704.EB3463A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: Saish Verification Token: PNKKz9aI -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:12:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:12:25 -0000 Subject: [GHC] #13312: GHC fatal error building Stack Message-ID: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> #13312: GHC fatal error building Stack -------------------------------------+------------------------------------- Reporter: Saish | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- stack upgrade --install-ghc Fetching package index ...remote: Counting objects: 11, done. remote: Compressing objects: 100% (9/9), done. remote: Total 11 (delta 3), reused 9 (delta 2), pack-reused 0 Unpacking objects: 100% (11/11), done. From https://github.com/commercialhaskell/all-cabal-hashes + 3568d98...c0c0122 hackage -> origin/hackage (forced update) t [tag update] current-hackage -> current-hackage Fetched package index. Populated index cache. aeson-1.0.2.1: configure aeson-1.0.2.1: build http-client-0.5.3.3: configure http-client-0.5.3.3: build pid1-0.1.0.0: configure pid1-0.1.0.0: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build pid1-0.1.0.0: copy/register store-core-0.3: configure store-core-0.3: build store-core-0.3: copy/register text-metrics-0.1.0: configure text-metrics-0.1.0: build text-metrics-0.1.0: copy/register th-orphans-0.13.1: configure th-orphans-0.13.1: build optparse-applicative-0.13.0.0: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build th-orphans-0.13.1: copy/register th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-simple-0.0.3: copy/register http-client-0.5.3.3: copy/register http-client-tls-0.3.3: configure http-client-tls-0.3.3: build http-client-tls-0.3.3: copy/register th-utilities-0.2.0.1: copy/register store-0.3: configure store-0.3: build store-0.3: copy/register aeson-1.0.2.1: copy/register aeson-compat-0.3.6: configure aeson-compat-0.3.6: build binary-tagged-0.1.4.1: configure binary-tagged-0.1.4.1: build path-0.5.9: configure path-0.5.9: build http-conduit-2.2.3: configure aeson-compat-0.3.6: copy/register http-conduit-2.2.3: build persistent-2.6: configure persistent-2.6: build path-0.5.9: copy/register path-io-1.1.0: configure http-conduit-2.2.3: copy/register path-io-1.1.0: build yaml-0.8.20: configure yaml-0.8.20: build binary-tagged-0.1.4.1: copy/register path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.15.0: configure hpack-0.15.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure persistent-sqlite-2.6: build hpack-0.15.0: copy/register persistent-template-2.5.1.6: copy/register persistent-sqlite-2.6: copy/register stack-1.3.2: configure [1 of 1] Compiling Main ( /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/Setup.hs, /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.3.2... stack-1.3.2: build Preprocessing library stack-1.3.2... [ 1 of 121] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 121] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 121] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 121] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 5 of 121] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 121] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 7 of 121] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 121] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 121] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/ghc34708_0/libghc_57.dylib, 5): no suitable image found. Did find: /var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/ghc34708_0/libghc_57.dylib: malformed mach-o: load commands size (48264) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 22 action(s). -- While building package stack-1.3.2 using: /private/var/folders/g8/2ssh5dld40s209dhvk17hxlsx0b760/T/stack- upgrade32684/stack-1.3.2/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:25:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:25:19 -0000 Subject: [GHC] #13312: GHC fatal error building Stack In-Reply-To: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> References: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> Message-ID: <059.e866df31638385aa7f834efcd95cd711@haskell.org> #13312: GHC fatal error building Stack -------------------------------------+------------------------------------- Reporter: Saish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 mpickering): * status: new => closed * resolution: => duplicate Comment: See #12479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:44:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:44:41 -0000 Subject: [GHC] #13271: GHC Panic With Injective Type Families In-Reply-To: <050.85e94bb0ec476229be5da928608f3194@haskell.org> References: <050.85e94bb0ec476229be5da928608f3194@haskell.org> Message-ID: <065.90af3598a72aa433911748c44083e13a@haskell.org> #13271: GHC Panic With Injective Type Families ---------------------------------+---------------------------------------- Reporter: wayofthepie | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0c9d9dec0a924a4f34f4cff26d004143c028861a/ghc" 0c9d9de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c9d9dec0a924a4f34f4cff26d004143c028861a" Remove panics for TcTyCon Previously TcTyCons were used only for knot-tying, but now they are also used after an error, to add a benign TyCon to the envt so we can carry on; see TyCon.makeRecoveryTyCon. But since it is used in this way, subsequent declarations may see a TcTyCon (e.g. during injectivity checks) and should not have a heart attack as a result. See Note [TcTyCon] in TyCon. This fixes Trac #13271 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:44:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:44:41 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.d88a90453de5fe675e657646fc06fb56@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) 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 Simon Peyton Jones ): In [changeset:"c7508083388a71d76a5b6f1e46adfbcffba74b96/ghc" c7508083/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c7508083388a71d76a5b6f1e46adfbcffba74b96" Disallow class instances for synonyms See Trac #13267 and Note [Instances and constraint synonyms] in TcValidity. We can't easily do a perfect job, because the rename is really trying to do its lookup too early. But this is at least an improvement. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:44:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:44:41 -0000 Subject: [GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W In-Reply-To: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> References: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> Message-ID: <066.fdabcfab47a2fd179bb3a8789edd36b4@haskell.org> #13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"499a15db0d71a9d0b91cbd5f509dabff50df2566/ghc" 499a15d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="499a15db0d71a9d0b91cbd5f509dabff50df2566" Test Trac #13300 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:44:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:44:41 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.53995280d64ab2748f51625e0c4428a0@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3c62b1d6b672e7727ea5fa56c69bf43e43d0fd8f/ghc" 3c62b1d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3c62b1d6b672e7727ea5fa56c69bf43e43d0fd8f" Gather constraints locally in checkMain Wiwth -fdefer-type-errors we were generating some top-level equality constraints, just in a corner of checkMain. The fix is easy. Fixes Trac #13292 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:46:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:46:24 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.52be4d0fbaa0fa84bb4487506b0e328c@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) 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: GHC accepts | Test Case: invalid program | polykinds/T13267 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T13267 * status: new => closed * resolution: => fixed Comment: Not perfect, but enough! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:47:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:47:12 -0000 Subject: [GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W In-Reply-To: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> References: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> Message-ID: <066.1f77152da688b74c0e5f3acaf8bdd0fa@haskell.org> #13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fine in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:47:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:47:56 -0000 Subject: [GHC] #13292: Type checker rejects ambiguous top level declaration. In-Reply-To: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> References: <044.ee00df58c2307512f5a1ec022b4dff15@haskell.org> Message-ID: <059.010ff2b5cbea458f49f862799d225574@haskell.org> #13292: Type checker rejects ambiguous top level declaration. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: | typecheck/should_fail/T13292 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T13292 * resolution: => fixed Comment: Thanks. There was a real bug here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 17:55:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 17:55:10 -0000 Subject: [GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W In-Reply-To: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> References: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> Message-ID: <066.d63c214424b83d2710f2cea3947caac8@haskell.org> #13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Fixed by the fix for #13271 I suppose? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:02:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:02:31 -0000 Subject: [GHC] #13289: Terrible loss of optimisation in presence of ticks In-Reply-To: <046.a52cdffdf54b8734a47f5857beb2785f@haskell.org> References: <046.a52cdffdf54b8734a47f5857beb2785f@haskell.org> Message-ID: <061.6a68c2e8af1530a65f3c01447a4f25ba@haskell.org> #13289: Terrible loss of optimisation in presence of ticks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Profiling Operating System: 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): `splitCont` looks like it separates out any outer type applications and coercions from the continuation, so in `(a,b) = splitCont c`, `a` is a continuation that consists only of the outer type applications and coercions from `c`, and `b` is the rest of the continuation. In order to transform `(tick t e) a` into `tick t (e a)`, the conditions should be * Either `a` is a type, or * `tickishScopesLike t NoScope` the second condition says that we must not float things in or out of the tick. (This `tickishScopesLike` thing is Peter's, I'm not all that familiar with it but I think this is right) The other thing that the current code is doing is pushing coercions inside the tick, which is always safe (and probably a good idea, given that I made it do this before). But it's slightly strange that this code appears to be lifting ticks out of type applications, whereas `CoreUtils.mkTick` is doing exactly the opposite! I have no idea why. The semantics wouldn't tell us; both are safe to do (like, say, floating a `let` outside an application), it's just a question of which one gives the best results. There are a couple of things we can do here: - Run the profiling tests in `testsuite/tests/profiling` - Run nofib with profiling on So I suggest making the change you propose, put it up on Phab, and also run the tests and nofib to check whether the changes don't introduce obvious regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:21:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:21:32 -0000 Subject: [GHC] #13312: GHC fatal error building Stack In-Reply-To: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> References: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> Message-ID: <059.702aeeea028cc94f005048c1f94e9422@haskell.org> #13312: GHC fatal error building Stack -------------------------------------+------------------------------------- Reporter: Saish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by Saish): So, it sounds like there is no way yet to use GHC 8.0.1 with Stack? The discussion in the linked ticket was a bit over my head. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:22:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:22:03 -0000 Subject: [GHC] #13312: GHC fatal error building Stack In-Reply-To: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> References: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> Message-ID: <059.9d2d7ae4d424ae4a6becbf7ef81e2654@haskell.org> #13312: GHC fatal error building Stack -------------------------------------+------------------------------------- Reporter: Saish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): No, but you can use 8.0.2! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:25:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:25:57 -0000 Subject: [GHC] #13312: GHC fatal error building Stack In-Reply-To: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> References: <044.8cff56100e8f46313087e99436cd1fcb@haskell.org> Message-ID: <059.fb07fc97b66c1415aabd1c1a073b9e02@haskell.org> #13312: GHC fatal error building Stack -------------------------------------+------------------------------------- Reporter: Saish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by Saish): Ok, thank you for clarifying! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:54:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:54:01 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.f7b49667c8dac0aad0b6e0d1955be625@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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 bgamari): * milestone: 8.2.1 => 8.4.1 Comment: To get any further on this we would need to fix the Windows situation which won't be happening for 8.2. Bumping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:55:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:55:14 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators In-Reply-To: <044.2722f1013c64633fbf159145867daa0f@haskell.org> References: <044.2722f1013c64633fbf159145867daa0f@haskell.org> Message-ID: <059.ce31c8e4e0dd9e30de248f480e318b04@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 11400 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 18:56:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 18:56:37 -0000 Subject: [GHC] #12143: ApplicativeDo Fails to Desugar 'return True' In-Reply-To: <051.25105ae3fe7e38a6681426345f9fe806@haskell.org> References: <051.25105ae3fe7e38a6681426345f9fe806@haskell.org> Message-ID: <066.05a4df643a6e861d145525ef4d05132a@haskell.org> #12143: ApplicativeDo Fails to Desugar 'return True' -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10892 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 19:02:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 19:02:11 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives In-Reply-To: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> References: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> Message-ID: <061.9642fd8a60418c03033deab66c99a16b@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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 bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 19:13:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 19:13:18 -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.eac0531c3d5d199a78ef1efc488b240b@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: fixed | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | wiki:Typeable/BenGamari | -------------------------------------+------------------------------------- Changes (by bgamari): * wikipage: => wiki:Typeable/BenGamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 19:18:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 19:18: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.67de8017e016c7874a51d79c2344a157@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Typeable 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, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Personally, I am satisfied with the status quo of being able to write, {{{#!hs f :: (Typeable (a::k), Typeable k) => Proxy a -> TypeRep f = typeOf }}} oerjan, if you also think that this is satisfactory then feel free to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 19:21:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 19:21:25 -0000 Subject: [GHC] #11817: Add proper support for weak symbols to the runtime linker In-Reply-To: <044.9d336eb495121fb8a216ccf15f54097a@haskell.org> References: <044.9d336eb495121fb8a216ccf15f54097a@haskell.org> Message-ID: <059.15cc9efc3a9b96fbc00f60efab8e11d1@haskell.org> #11817: Add proper support for weak symbols to the runtime linker -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/linking/T3333, | rts/T11223/T11223_weak* Blocked By: | Blocking: Related Tickets: #11223, #3333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => Comment: not since #11223 that I'm aware of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 20:21:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 20:21:44 -0000 Subject: [GHC] #12665: Make Read instances for Integral types faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.5c62bbb66278791f06d3c848734de8a9@haskell.org> #12665: Make Read instances for Integral types faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.4.1 Component: Core Libraries | Version: 8.0.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 bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 20:30:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 20:30:59 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.2c3f4502a9f4eb63c08abe89149c8da8@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2. At this point it seems less and less likely that this will happen at all given that static pointers have been out in the wild for years now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 20:31:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 20:31:37 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.39de44da946b065b80f205335f32cc82@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Sadly yhis won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 20:35:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 20:35:02 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.da6a1a242fc7a86d7fc325c9e9b500da@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Regardless, this certainly won't be addressed for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 20:44:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 20:44:42 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.15c24be10631223c8f30954a7332c902@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.1 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 bgamari): * priority: normal => highest * component: Compiler => Compiler (LLVM) Comment: Bumping priority since this utterly breaks the LLVM backend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 21:20:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 21:20:37 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.1fd5dafd930ce6100bedde59d8e49665@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7398 | Differential Rev(s): Phab:D3169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D3169 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 21 23:59:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Feb 2017 23:59:03 -0000 Subject: [GHC] #13313: cabal08 broken Message-ID: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Upon updating the `Cabal` submodule from 19c278feb732f5797256ff28eb671440f5511c6c to e4c36b9dd51820f2380ce7a66f980c4e7b2e96fc the `cabal08` testcase broke. I've marked it as `expect_broken` for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:15:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:15:52 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.2d6640e96187dc7bd1b5512a7283cd82@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D3080 => Phab:D3080 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:17:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:17:01 -0000 Subject: [GHC] #13221: OccurAnal fails to rediscover join points In-Reply-To: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> References: <049.3ff47df0f86e62efbb83899614b0ad86@haskell.org> Message-ID: <064.c0259345d0d97c5e91d7a84f921dbca6@haskell.org> #13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe this was resolved in 795bc49ceb12cecf46e0c53a570809c3df85ab9a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:18:21 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.5cae0e5601b135d5cd9c3c52e85377ae@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Alright, if I understand correctly nothing will be happing on this front until 8.4 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:18:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:18:43 -0000 Subject: [GHC] #13163: Make type import/export API Annotation friendly In-Reply-To: <044.7fe6260ca2f7eb764d1cf3fd5f011712@haskell.org> References: <044.7fe6260ca2f7eb764d1cf3fd5f011712@haskell.org> Message-ID: <059.279dca96934ecdc5229259966ee58f2b@haskell.org> #13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | 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:D3016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:24:20 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.44e886f272dacf79141d345cae8cbbd2@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.1 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): Well, for better or worse using gold (by adding `EXTRA_HC_OPTS=-optl--use- ld=gold` to the `make` command line) works fine. It looks like this is probably a BFD `ld` bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:27:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:27:03 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.61fd648ea4da95433682017abf706f86@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): How did it break? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:30:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:30:40 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.e6ac464b4480f3d7fe046a35c62a0685@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm in the middle of another build to verify this, but this is what happened last time, {{{ diff --git a/testsuite/tests/cabal/cabal08/cabal08.stdout b/testsuite/tests/cabal/cabal08/cabal08.stdout index 8f97cd409f..bf196e0629 100644 --- a/testsuite/tests/cabal/cabal08/cabal08.stdout +++ b/testsuite/tests/cabal/cabal08/cabal08.stdout @@ -1,6 +1,6 @@ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... -p2 +p1 [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... -p2 +p1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:34:54 -0000 Subject: [GHC] #13196: Document AMP as a deviation from Haskell 2010 In-Reply-To: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> References: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> Message-ID: <060.dca5825a3e58c340ceb420fd238de3a6@haskell.org> #13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: AMP 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): Dfeuer, do you think we could get this taken care of before the release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:43:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:43:11 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.79e902fb00cecee51b033be8afa5999a@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I can reliably reproduce this. I've marked the test as broken in 8ccbc2e5252abd4fa67d155d4fff489ee9929906. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:51:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:51:21 -0000 Subject: [GHC] #13196: Document AMP as a deviation from Haskell 2010 In-Reply-To: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> References: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> Message-ID: <060.f5e61378031182ee54111d94b88fa4b7@haskell.org> #13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: AMP 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): Sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 00:55:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 00:55:03 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... In-Reply-To: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> References: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> Message-ID: <065.f9aeae4735652c28a92139fcddcafeb2@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12808 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Since in many cases, the use of the LLVM backend is the only way to avoid > the NCG's poor register allocation (ticket #8971), this is a concern that > using "-fllvm" is producing overly complex code through a (seeming) > failed attempt to optimize. > > The following code uses a very simple "odds-only" implementation of the > Sieve of Eratosthenes with a very tight inner culling loop limited to > using a 16 Kilobyte buffer (<= the size of most modern CPU L1 data cache > size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for > better speed than using a variable shift left operation for setting the > composite bits in the buffer array as it (should) take the same number of > registers and the array look-up instruction is easier for the CPU to fuse > than a variable shift left: > > {{{#!hs > -- GHC_EfficiencyBug.hs > {-# LANGUAGE FlexibleContexts #-} > {-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2 > > import Data.Word > import Data.Bits > import Data.Array.ST (runSTUArray) > import Data.Array.Base > > numLOOPS = 10000 :: Int > > twos :: UArray Int Word32 > twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] > > soe :: () -> [Word32] > soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where > bufb = runSTUArray $ do > let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = > 16 KBytes > cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) > cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int > Word32)) cmpstsb > let loop n = -- cull a number of times to test timing > if n <= 0 then return cmpstsb else > let cullp i = > let p = i + i + 3 in > let s = (p * p - 3) `div` 2 in > if s > bfLmt then loop (n - 1) else do > isCmpst <- unsafeRead cmpstsb i > if isCmpst then cullp (i + 1) else -- is Prime > let cull j = -- very tight inner loop where all the > time is spent > if j > bfLmt then cullp (i + 1) else do > let sh = unsafeAt twos (j .&. 31) -- (1 > `shiftL` (j .&. 31))) > let w = j `shiftR` 5 > ov <- unsafeRead cmpstsw w > unsafeWrite cmpstsw w (ov .|. sh) > cull (j + p) in cull s in cullp 0 > loop numLOOPS > > main = print $ length $ soe() > }}} > The main culling is repeated "numLOOPS" times to get a reasonable > execution time for accurate timing and to make the time required to use > the List comprehension to determine the number of found primes (the > answer) a negligible part of the execution time. Timing results can be > produced by running "./GHC_EfficiencyBug +RTS -s". > > The desired assembly code result for the tight inner loop is as for the > Rust/LLVM compiler, in this case for x86_64 64-bit code: > {{{ > .p2align 4, 0x90 > .LBB10_27: > movq %rcx, %rdx > shrq $5, %rdx > movl %ecx, %esi > andl $31, %esi > movl (%rbp,%rsi,4), %esi > orl %esi, (%r14,%rdx,4) > addq %rax, %rcx > .LBB10_26: > cmpq %r13, %rcx > jb .LBB10_27 > }}} > The above code is extremely efficient on a CPU that is not cache bottle > necked (such as the AMD Bulldozer series are) and takes just about three > clock cycles per inner composite culling loop on Intel Sky Lake; it is > just as efficient for x86 code since there are only seven registers used > in this inner loop. > > Due to this attempt at "over-optimization", the GHC/LLVM backend produces > the following x86_64 64-bit code: > {{{ > .align 16, 0x90 > .LBB34_2: # %c8T2 > # =>This Inner Loop Header: > Depth=1 > movq %rcx, %rsi > sarq $5, %rsi > movl %r8d, %edi > andl $124, %edi > movl 16(%rax,%rdi), %edi > orl %edi, 16(%r11,%rsi,4) > addq %r14, %rcx > addq %rdx, %r8 > cmpq %r10, %rcx > jle .LBB34_2 > }}} > As can be seen, instead of just masking the "twos" index register by 31 > (0x1F), the code is using two extra separate registers to contain "(j * > 4)" increment and the accumulated index, which increment is added to the > "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), > requiring an extra two registers and an extra instruction for the extra > addition. This isn't a problem as to the number of registers for x86_64 > code which has more than enough, but it adds the extra instruction > execution time of one third of a CPU clock cycle (I know, only one ninth > extra time). > > However, for 32-bit x86 code with barely enough registers previously, the > use of the extra registers triggers a chain of three register reloads as > can be seen in the following assembly code: > {{{ > .align 16, 0x90 > LBB33_2: # %c8Wb > # =>This Inner Loop Header: > Depth=1 > movl %ebx, %ebp > sarl $5, %ebp > movl %edi, %ecx > andl $124, %ecx > movl %esi, %edx > movl %eax, %esi > movl 36(%esp), %eax # 4-byte Reload > movl 8(%eax,%ecx), %ecx > movl %esi, %eax > movl %edx, %esi > orl %ecx, 8(%esi,%ebp,4) > addl 32(%esp), %ebx # 4-byte Folded Reload > addl 28(%esp), %edi # 4-byte Folded Reload > cmpl %eax, %ebx > jle LBB33_2 > }}} > '''The above code runs about 25% slower than it should on Intel Sky Lake > for this 32-bit code.''' > > This was tested for GHC version 8.0.1 under both Windows and Linux for > both 32-bit and 64-bit code with identical results for each native code > width. > > The code was also tested for 32 and 64 bit code produced by the NCG; for > this specific problem, NCG takes the simple approach and does not waste > the extra register. However, due to the inefficient allocation of > registers as per ticket #8971, not moving the loop completion check to > the end of the loop and thus requiring an extra jump instruction, and not > combining the read/modify/write into a single instruction, it is still > slower (much slower for 32-bit code) than the LLVM produced code. As its > problems are known, I have not documented the NCG code. > > Conclusion: This may seem like a nit picky type of bug as in some use > cases the execution time cost is very small, but it may be an indication > of problems in other use cases that cause more serious effects on > execution speed. It is my feeling that for such low level somewhat > imperative types of code, GHC should really produce code that is as fast > as C/C++/Rust. New description: Since in many cases, the use of the LLVM backend is the only way to avoid the NCG's poor register allocation (ticket #8971), this is a concern that using "-fllvm" is producing overly complex code through a (seeming) failed attempt to optimize. The following code uses a very simple "odds-only" implementation of the Sieve of Eratosthenes with a very tight inner culling loop limited to using a 16 Kilobyte buffer (<= the size of most modern CPU L1 data cache size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for better speed than using a variable shift left operation for setting the composite bits in the buffer array as it (should) take the same number of registers and the array look-up instruction is easier for the CPU to fuse than a variable shift left: {{{#!hs -- GHC_EfficiencyBug.hs {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2 import Control.Monad.ST import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base numLOOPS = 10000 :: Int twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soe :: () -> [Word32] soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfLmt then loop (n - 1) else do isCmpst <- unsafeRead cmpstsb i if isCmpst then cullp (i + 1) else -- is Prime let cull j = -- very tight inner loop where all the time is spent if j > bfLmt then cullp (i + 1) else do let sh = unsafeAt twos (j .&. 31) -- (1 `shiftL` (j .&. 31))) let w = j `shiftR` 5 ov <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (ov .|. sh) cull (j + p) in cull s in cullp 0 loop numLOOPS main = print $ length $ soe() }}} The main culling is repeated "numLOOPS" times to get a reasonable execution time for accurate timing and to make the time required to use the List comprehension to determine the number of found primes (the answer) a negligible part of the execution time. Timing results can be produced by running "./GHC_EfficiencyBug +RTS -s". The desired assembly code result for the tight inner loop is as for the Rust/LLVM compiler, in this case for x86_64 64-bit code: {{{ .p2align 4, 0x90 .LBB10_27: movq %rcx, %rdx shrq $5, %rdx movl %ecx, %esi andl $31, %esi movl (%rbp,%rsi,4), %esi orl %esi, (%r14,%rdx,4) addq %rax, %rcx .LBB10_26: cmpq %r13, %rcx jb .LBB10_27 }}} The above code is extremely efficient on a CPU that is not cache bottle necked (such as the AMD Bulldozer series are) and takes just about three clock cycles per inner composite culling loop on Intel Sky Lake; it is just as efficient for x86 code since there are only seven registers used in this inner loop. Due to this attempt at "over-optimization", the GHC/LLVM backend produces the following x86_64 64-bit code: {{{ .align 16, 0x90 .LBB34_2: # %c8T2 # =>This Inner Loop Header: Depth=1 movq %rcx, %rsi sarq $5, %rsi movl %r8d, %edi andl $124, %edi movl 16(%rax,%rdi), %edi orl %edi, 16(%r11,%rsi,4) addq %r14, %rcx addq %rdx, %r8 cmpq %r10, %rcx jle .LBB34_2 }}} As can be seen, instead of just masking the "twos" index register by 31 (0x1F), the code is using two extra separate registers to contain "(j * 4)" increment and the accumulated index, which increment is added to the "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), requiring an extra two registers and an extra instruction for the extra addition. This isn't a problem as to the number of registers for x86_64 code which has more than enough, but it adds the extra instruction execution time of one third of a CPU clock cycle (I know, only one ninth extra time). However, for 32-bit x86 code with barely enough registers previously, the use of the extra registers triggers a chain of three register reloads as can be seen in the following assembly code: {{{ .align 16, 0x90 LBB33_2: # %c8Wb # =>This Inner Loop Header: Depth=1 movl %ebx, %ebp sarl $5, %ebp movl %edi, %ecx andl $124, %ecx movl %esi, %edx movl %eax, %esi movl 36(%esp), %eax # 4-byte Reload movl 8(%eax,%ecx), %ecx movl %esi, %eax movl %edx, %esi orl %ecx, 8(%esi,%ebp,4) addl 32(%esp), %ebx # 4-byte Folded Reload addl 28(%esp), %edi # 4-byte Folded Reload cmpl %eax, %ebx jle LBB33_2 }}} '''The above code runs about 25% slower than it should on Intel Sky Lake for this 32-bit code.''' This was tested for GHC version 8.0.1 under both Windows and Linux for both 32-bit and 64-bit code with identical results for each native code width. The code was also tested for 32 and 64 bit code produced by the NCG; for this specific problem, NCG takes the simple approach and does not waste the extra register. However, due to the inefficient allocation of registers as per ticket #8971, not moving the loop completion check to the end of the loop and thus requiring an extra jump instruction, and not combining the read/modify/write into a single instruction, it is still slower (much slower for 32-bit code) than the LLVM produced code. As its problems are known, I have not documented the NCG code. Conclusion: This may seem like a nit picky type of bug as in some use cases the execution time cost is very small, but it may be an indication of problems in other use cases that cause more serious effects on execution speed. It is my feeling that for such low level somewhat imperative types of code, GHC should really produce code that is as fast as C/C++/Rust. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 01:03:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 01:03:52 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... In-Reply-To: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> References: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> Message-ID: <065.c2ea260ec93d2ebefefb3754b3baad70@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12808 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Since in many cases, the use of the LLVM backend is the only way to avoid > the NCG's poor register allocation (ticket #8971), this is a concern that > using "-fllvm" is producing overly complex code through a (seeming) > failed attempt to optimize. > > The following code uses a very simple "odds-only" implementation of the > Sieve of Eratosthenes with a very tight inner culling loop limited to > using a 16 Kilobyte buffer (<= the size of most modern CPU L1 data cache > size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for > better speed than using a variable shift left operation for setting the > composite bits in the buffer array as it (should) take the same number of > registers and the array look-up instruction is easier for the CPU to fuse > than a variable shift left: > > {{{#!hs > -- GHC_EfficiencyBug.hs > {-# LANGUAGE FlexibleContexts #-} > {-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2 > > import Control.Monad.ST > import Data.Word > import Data.Bits > import Data.Array.ST (runSTUArray) > import Data.Array.Base > > numLOOPS = 10000 :: Int > > twos :: UArray Int Word32 > twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] > > soe :: () -> [Word32] > soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where > bufb = runSTUArray $ do > let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = > 16 KBytes > cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) > cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int > Word32)) cmpstsb > let loop n = -- cull a number of times to test timing > if n <= 0 then return cmpstsb else > let cullp i = > let p = i + i + 3 in > let s = (p * p - 3) `div` 2 in > if s > bfLmt then loop (n - 1) else do > isCmpst <- unsafeRead cmpstsb i > if isCmpst then cullp (i + 1) else -- is Prime > let cull j = -- very tight inner loop where all the > time is spent > if j > bfLmt then cullp (i + 1) else do > let sh = unsafeAt twos (j .&. 31) -- (1 > `shiftL` (j .&. 31))) > let w = j `shiftR` 5 > ov <- unsafeRead cmpstsw w > unsafeWrite cmpstsw w (ov .|. sh) > cull (j + p) in cull s in cullp 0 > loop numLOOPS > > main = print $ length $ soe() > }}} > The main culling is repeated "numLOOPS" times to get a reasonable > execution time for accurate timing and to make the time required to use > the List comprehension to determine the number of found primes (the > answer) a negligible part of the execution time. Timing results can be > produced by running "./GHC_EfficiencyBug +RTS -s". > > The desired assembly code result for the tight inner loop is as for the > Rust/LLVM compiler, in this case for x86_64 64-bit code: > {{{ > .p2align 4, 0x90 > .LBB10_27: > movq %rcx, %rdx > shrq $5, %rdx > movl %ecx, %esi > andl $31, %esi > movl (%rbp,%rsi,4), %esi > orl %esi, (%r14,%rdx,4) > addq %rax, %rcx > .LBB10_26: > cmpq %r13, %rcx > jb .LBB10_27 > }}} > The above code is extremely efficient on a CPU that is not cache bottle > necked (such as the AMD Bulldozer series are) and takes just about three > clock cycles per inner composite culling loop on Intel Sky Lake; it is > just as efficient for x86 code since there are only seven registers used > in this inner loop. > > Due to this attempt at "over-optimization", the GHC/LLVM backend produces > the following x86_64 64-bit code: > {{{ > .align 16, 0x90 > .LBB34_2: # %c8T2 > # =>This Inner Loop Header: > Depth=1 > movq %rcx, %rsi > sarq $5, %rsi > movl %r8d, %edi > andl $124, %edi > movl 16(%rax,%rdi), %edi > orl %edi, 16(%r11,%rsi,4) > addq %r14, %rcx > addq %rdx, %r8 > cmpq %r10, %rcx > jle .LBB34_2 > }}} > As can be seen, instead of just masking the "twos" index register by 31 > (0x1F), the code is using two extra separate registers to contain "(j * > 4)" increment and the accumulated index, which increment is added to the > "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), > requiring an extra two registers and an extra instruction for the extra > addition. This isn't a problem as to the number of registers for x86_64 > code which has more than enough, but it adds the extra instruction > execution time of one third of a CPU clock cycle (I know, only one ninth > extra time). > > However, for 32-bit x86 code with barely enough registers previously, the > use of the extra registers triggers a chain of three register reloads as > can be seen in the following assembly code: > {{{ > .align 16, 0x90 > LBB33_2: # %c8Wb > # =>This Inner Loop Header: > Depth=1 > movl %ebx, %ebp > sarl $5, %ebp > movl %edi, %ecx > andl $124, %ecx > movl %esi, %edx > movl %eax, %esi > movl 36(%esp), %eax # 4-byte Reload > movl 8(%eax,%ecx), %ecx > movl %esi, %eax > movl %edx, %esi > orl %ecx, 8(%esi,%ebp,4) > addl 32(%esp), %ebx # 4-byte Folded Reload > addl 28(%esp), %edi # 4-byte Folded Reload > cmpl %eax, %ebx > jle LBB33_2 > }}} > '''The above code runs about 25% slower than it should on Intel Sky Lake > for this 32-bit code.''' > > This was tested for GHC version 8.0.1 under both Windows and Linux for > both 32-bit and 64-bit code with identical results for each native code > width. > > The code was also tested for 32 and 64 bit code produced by the NCG; for > this specific problem, NCG takes the simple approach and does not waste > the extra register. However, due to the inefficient allocation of > registers as per ticket #8971, not moving the loop completion check to > the end of the loop and thus requiring an extra jump instruction, and not > combining the read/modify/write into a single instruction, it is still > slower (much slower for 32-bit code) than the LLVM produced code. As its > problems are known, I have not documented the NCG code. > > Conclusion: This may seem like a nit picky type of bug as in some use > cases the execution time cost is very small, but it may be an indication > of problems in other use cases that cause more serious effects on > execution speed. It is my feeling that for such low level somewhat > imperative types of code, GHC should really produce code that is as fast > as C/C++/Rust. New description: Since in many cases, the use of the LLVM backend is the only way to avoid the NCG's poor register allocation (ticket #8971), this is a concern that using "-fllvm" is producing overly complex code through a (seeming) failed attempt to optimize. The following code uses a very simple "odds-only" implementation of the Sieve of Eratosthenes with a very tight inner culling loop limited to using a 16 Kilobyte buffer (<= the size of most modern CPU L1 data cache size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for better speed than using a variable shift left operation for setting the composite bits in the buffer array as it (should) take the same number of registers and the array look-up instruction is easier for the CPU to fuse than a variable shift left: {{{#!hs -- GHC_EfficiencyBug.hs {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2 import Control.Monad.ST import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base numLOOPS = 10000 :: Int twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soe :: () -> [Word32] soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfLmt then loop (n - 1) else do isCmpst <- unsafeRead cmpstsb i if isCmpst then cullp (i + 1) else -- is Prime let cull j = -- very tight inner loop where all the time is spent if j > bfLmt then cullp (i + 1) else do let sh = unsafeAt twos (j .&. 31) -- (1 `shiftL` (j .&. 31))) let w = j `shiftR` 5 ov <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (ov .|. sh) cull (j + p) in cull s in cullp 0 loop numLOOPS main = print $ length $ soe() }}} The main culling is repeated "numLOOPS" times to get a reasonable execution time for accurate timing and to make the time required to use the List comprehension to determine the number of found primes (the answer) a negligible part of the execution time. Timing results can be produced by running "./GHC_EfficiencyBug +RTS -s". The desired assembly code result for the tight inner loop is as for the Rust/LLVM compiler, in this case for x86_64 64-bit code: {{{ .p2align 4, 0x90 .LBB10_27: movq %rcx, %rdx shrq $5, %rdx movl %ecx, %esi andl $31, %esi movl (%rbp,%rsi,4), %esi orl %esi, (%r14,%rdx,4) addq %rax, %rcx .LBB10_26: cmpq %r13, %rcx jb .LBB10_27 }}} The above code is extremely efficient on a CPU that is not cache bottle necked (such as the AMD Bulldozer series are) and takes just about three clock cycles per inner composite culling loop on Intel Sky Lake; it is just as efficient for x86 code since there are only seven registers used in this inner loop. Due to this attempt at "over-optimization", the GHC/LLVM backend produces the following x86_64 64-bit code: {{{ .align 16, 0x90 .LBB34_2: # %c8T2 # =>This Inner Loop Header: Depth=1 movq %rcx, %rsi sarq $5, %rsi movl %r8d, %edi andl $124, %edi movl 16(%rax,%rdi), %edi orl %edi, 16(%r11,%rsi,4) addq %r14, %rcx addq %rdx, %r8 cmpq %r10, %rcx jle .LBB34_2 }}} As can be seen, instead of just masking the "twos" index register by 31 (0x1F), the code is using two extra separate registers to contain "(j * 4)" increment and the accumulated index, which increment is added to the "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), requiring an extra two registers and an extra instruction for the extra addition. This isn't a problem as to the number of registers for x86_64 code which has more than enough, but it adds the extra instruction execution time of one third of a CPU clock cycle (I know, only one ninth extra time). However, for 32-bit x86 code with barely enough registers previously, the use of the extra registers triggers a chain of three register reloads as can be seen in the following assembly code: {{{ .align 16, 0x90 LBB33_2: # %c8Wb # =>This Inner Loop Header: Depth=1 movl %ebx, %ebp sarl $5, %ebp movl %edi, %ecx andl $124, %ecx movl %esi, %edx movl %eax, %esi movl 36(%esp), %eax # 4-byte Reload movl 8(%eax,%ecx), %ecx movl %esi, %eax movl %edx, %esi orl %ecx, 8(%esi,%ebp,4) addl 32(%esp), %ebx # 4-byte Folded Reload addl 28(%esp), %edi # 4-byte Folded Reload cmpl %eax, %ebx jle LBB33_2 }}} '''The above code runs about 25% slower than it should on Intel Sky Lake for this 32-bit code.''' This was tested for GHC version 8.0.1 under both Windows and Linux for both 32-bit and 64-bit code with identical results for each native code width. The code was also tested for 32 and 64 bit code produced by the NCG; for this specific problem, NCG takes the simple approach and does not waste the extra register. However, due to the inefficient allocation of registers as per ticket #8971, not moving the loop completion check to the end of the loop and thus requiring an extra jump instruction, and not combining the read/modify/write into a single instruction, it is still slower (much slower for 32-bit code) than the LLVM produced code. As its problems are known, I have not documented the NCG code. Conclusion: This may seem like a nit picky type of bug as in some use cases the execution time cost is very small, but it may be an indication of problems in other use cases that cause more serious effects on execution speed. It is my feeling that for such low level somewhat imperative types of code, GHC should really produce code that is as fast as C/C++/Rust. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 01:23:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 01:23:11 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together Message-ID: <051.b7801bef233825925572c80f723674d2@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm starting with the `SPretty` example from the `DeriveAnyClass` section in the GHC users guide: {{{#!hs #!/usr/bin/env stack -- stack --resolver lts-8.0 {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} import Prelude import Numeric.Natural (Natural) class SPretty a where sPpr :: a -> String default sPpr :: Show a => a -> String sPpr = show }}} I can write an empty instance for `Natural`: {{{#!hs instance SPretty Natural where }}} So then I would expect to be able to write an equivalent definition using standalone deriving: {{{#!hs deriving instance SPretty Natural }}} But instead it fails with this error: {{{ error: • Can't make a derived instance of ‘SPretty Natural’: The data constructors of ‘Natural’ are not all in scope so you cannot derive an instance for it • In the stand-alone deriving instance for ‘SPretty Natural’ }}} It seems like this ought to work; I'm not sure why the constructors should need to be in scope, given that the instance can be derived trivially without defining any methods. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 01:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 01:42:51 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together In-Reply-To: <051.b7801bef233825925572c80f723674d2@haskell.org> References: <051.b7801bef233825925572c80f723674d2@haskell.org> Message-ID: <066.0b017308b2afbe0d5892a105469e1093@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: Old description: > I'm starting with the `SPretty` example from the `DeriveAnyClass` section > in the GHC users guide: > > {{{#!hs > #!/usr/bin/env stack > -- stack --resolver lts-8.0 > {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} > > import Prelude > import Numeric.Natural (Natural) > > class SPretty a where > sPpr :: a -> String > default sPpr :: Show a => a -> String > sPpr = show > }}} > > I can write an empty instance for `Natural`: > > {{{#!hs > instance SPretty Natural where > }}} > > So then I would expect to be able to write an equivalent definition using > standalone deriving: > > {{{#!hs > deriving instance SPretty Natural > }}} > > But instead it fails with this error: > > {{{ > error: > • Can't make a derived instance of ‘SPretty Natural’: > The data constructors of ‘Natural’ are not all in scope > so you cannot derive an instance for it > • In the stand-alone deriving instance for ‘SPretty Natural’ > }}} > > It seems like this ought to work; I'm not sure why the constructors > should need to be in scope, given that the instance can be derived > trivially without defining any methods. New description: I'm starting with the `SPretty` example from the `DeriveAnyClass` section in the GHC users guide: {{{#!hs #!/usr/bin/env stack -- stack --resolver lts-8.0 {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} import Prelude import Numeric.Natural (Natural) class SPretty a where sPpr :: a -> String default sPpr :: Show a => a -> String sPpr = show }}} I can write an empty instance for `Natural`: {{{#!hs instance SPretty Natural where }}} So then I would expect to be able to write an equivalent definition using standalone deriving: {{{#!hs deriving instance SPretty Natural }}} But instead it fails with this error: {{{ error: • Can't make a derived instance of ‘SPretty Natural’: The data constructors of ‘Natural’ are not all in scope so you cannot derive an instance for it • In the stand-alone deriving instance for ‘SPretty Natural’ }}} It seems like this ought to work; I'm not sure why the constructors should need to be in scope, given that the instance can be derived trivially without defining any methods. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 01:44:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 01:44:33 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together In-Reply-To: <051.b7801bef233825925572c80f723674d2@haskell.org> References: <051.b7801bef233825925572c80f723674d2@haskell.org> Message-ID: <066.c27a154fbdd99af7c61f2134ff4918d9@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: Old description: > I'm starting with the `SPretty` example from the `DeriveAnyClass` section > in the GHC users guide: > > {{{#!hs > #!/usr/bin/env stack > -- stack --resolver lts-8.0 > {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} > > import Prelude > import Numeric.Natural (Natural) > > class SPretty a where > sPpr :: a -> String > default sPpr :: Show a => a -> String > sPpr = show > }}} > > I can write an empty instance for `Natural`: > > {{{#!hs > instance SPretty Natural where > }}} > > So then I would expect to be able to write an equivalent definition using > standalone deriving: > > {{{#!hs > deriving instance SPretty Natural > }}} > > But instead it fails with this error: > > {{{ > error: > • Can't make a derived instance of ‘SPretty Natural’: > The data constructors of ‘Natural’ are not all in scope > so you cannot derive an instance for it > • In the stand-alone deriving instance for ‘SPretty Natural’ > }}} > > It seems like this ought to work; I'm not sure why the constructors > should need to be in scope, given that the instance can be derived > trivially without defining any methods. New description: I'm starting with the `SPretty` example from the `DeriveAnyClass` section in the GHC users guide: {{{#!hs #!/usr/bin/env stack -- stack --resolver lts-8.0 {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} import Prelude import Numeric.Natural (Natural) class SPretty a where sPpr :: a -> String default sPpr :: Show a => a -> String sPpr = show }}} I can write an empty instance for `Natural`: {{{#!hs instance SPretty Natural where }}} So then I would expect to be able to write an equivalent definition using standalone-deriving and derive-and-class: {{{#!hs deriving instance SPretty Natural }}} But instead it fails with this error: {{{ error: • Can't make a derived instance of ‘SPretty Natural’: The data constructors of ‘Natural’ are not all in scope so you cannot derive an instance for it • In the stand-alone deriving instance for ‘SPretty Natural’ }}} It seems like this ought to work; I'm not sure why the constructors should need to be in scope, given that the instance can be derived trivially without defining any methods. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 01:45:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 01:45:04 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together In-Reply-To: <051.b7801bef233825925572c80f723674d2@haskell.org> References: <051.b7801bef233825925572c80f723674d2@haskell.org> Message-ID: <066.f1156f68029bb147a9cb9f3449cac773@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: Old description: > I'm starting with the `SPretty` example from the `DeriveAnyClass` section > in the GHC users guide: > > {{{#!hs > #!/usr/bin/env stack > -- stack --resolver lts-8.0 > {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} > > import Prelude > import Numeric.Natural (Natural) > > class SPretty a where > sPpr :: a -> String > default sPpr :: Show a => a -> String > sPpr = show > }}} > > I can write an empty instance for `Natural`: > > {{{#!hs > instance SPretty Natural where > }}} > > So then I would expect to be able to write an equivalent definition using > standalone-deriving and derive-and-class: > > {{{#!hs > deriving instance SPretty Natural > }}} > > But instead it fails with this error: > > {{{ > error: > • Can't make a derived instance of ‘SPretty Natural’: > The data constructors of ‘Natural’ are not all in scope > so you cannot derive an instance for it > • In the stand-alone deriving instance for ‘SPretty Natural’ > }}} > > It seems like this ought to work; I'm not sure why the constructors > should need to be in scope, given that the instance can be derived > trivially without defining any methods. New description: I'm starting with the `SPretty` example from the `DeriveAnyClass` section in the GHC users guide: {{{#!hs #!/usr/bin/env stack -- stack --resolver lts-8.0 {-# LANGUAGE DefaultSignatures, DeriveAnyClass, StandaloneDeriving #-} import Prelude import Numeric.Natural (Natural) class SPretty a where sPpr :: a -> String default sPpr :: Show a => a -> String sPpr = show }}} I can write an empty instance for `Natural`: {{{#!hs instance SPretty Natural where }}} So then I would expect to be able to write an equivalent definition using `StandaloneDeriving` and `DeriveAnyClass`: {{{#!hs deriving instance SPretty Natural }}} But instead it fails with this error: {{{ error: • Can't make a derived instance of ‘SPretty Natural’: The data constructors of ‘Natural’ are not all in scope so you cannot derive an instance for it • In the stand-alone deriving instance for ‘SPretty Natural’ }}} It seems like this ought to work; I'm not sure why the constructors should need to be in scope, given that the instance can be derived trivially without defining any methods. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 02:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 02:00:11 -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.853e9442030232bbc807e5b30d8f6621@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Typeable 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, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * status: new => closed * resolution: => wontfix Comment: Yes, I see that even my "kitchen sink" example can be fixed with a simple `Typeable k` constraint. And as in my previous comment, such constraints can be inferred too. So since I don't know any examples that this doesn't suffice for, I'll close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 02:04:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 02:04:25 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together In-Reply-To: <051.b7801bef233825925572c80f723674d2@haskell.org> References: <051.b7801bef233825925572c80f723674d2@haskell.org> Message-ID: <066.c4699504e661aecfe8cfb1dea50ac8eb@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | 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 rwbarton): * status: new => closed * cc: RyanGlScott (added) * resolution: => fixed Comment: Happily this works with the revamped `DeriveAnyClass` logic in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 02:12:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 02:12:55 -0000 Subject: [GHC] #13314: StandaloneDeriving and DeriveAnyClass don't work together In-Reply-To: <051.b7801bef233825925572c80f723674d2@haskell.org> References: <051.b7801bef233825925572c80f723674d2@haskell.org> Message-ID: <066.e5111e2cc3cfcfc622fc51e75cbb118e@haskell.org> #13314: StandaloneDeriving and DeriveAnyClass don't work together -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: #11509 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics * related: => #11509 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 07:53:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 07:53:36 -0000 Subject: [GHC] #13315: Compile broken on new MSYS2 Message-ID: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> #13315: Compile broken on new MSYS2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- February comes with a major change in behavior for MSYS2/Cygwin. Tools such as awk/sed etc now use binary mode unless on a text mount: https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html This is problematic because GHC etc only use the underlying OS to determine how to output line endings. As such we output \r\n but in sed et al $ will no longer match line endings. Which means out scripts are currently broken. The build will fail with errors such as {{{ [00:09:33][Step 2/6] utils/hp2ps/dist/build/.depend.c_asm:2: *** missing separator. Stop. [00:09:33][Step 2/6] make: *** [Makefile:125: all] Error 2 }}} This is because the `--make-depends` output from GHC will write a file using `\r\n` newlines which `sed` et al will no longer match with `$`. This change is pretty catastrophic in that it also applies to piped data from stdout/stderr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 07:56:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 07:56:04 -0000 Subject: [GHC] #13315: Compile broken on new MSYS2 In-Reply-To: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> References: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> Message-ID: <059.82a95a35d94b3ab96ccfe5da0a1ec4a1@haskell.org> #13315: Compile broken on new MSYS2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): The only workaround I have found so far that works reliably is forcing the mounts to be text mounts. My `/ect/fstab` contains {{{ none / cygdrive text,posix=0,noacl,user 0 0 C:/TeamCity/buildAgent/work /c/TeamCity/buildAgent/work ntfs text,posix=0,noacl,user 0 0 }}} It seems to be important to also force the `/` to be a text mount. The tools seem to look at the path they're in to determine how to behave. note that the output of `mount` does not reflect the change of the `/` mount, but it does work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 08:45:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 08:45:39 -0000 Subject: [GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W In-Reply-To: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> References: <051.f7b2e9a77d1accc51d7921891f939143@haskell.org> Message-ID: <066.c6d612f70d2c65c240c3aeb79749603a@haskell.org> #13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually this particular one appeared to be fixed before; I'm not sure how. But we have a regression test for it now, so all good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 09:27:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 09:27:16 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.f4745fac957455ccfa076712bcb4140a@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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): OK here's what I can do easily. Let's say that in a `Stmt` {{{ pat <- rhs }}} * the `Stmt` ''requires'' constraints needed to typecheck `rhs`, and to pattern-match `pat` (e.g. in a view pattern) * the `Stmt` ''binds'' the existential type variables and constraints brought into scope by the pattern `pat` So for example, given {{{ data T a where MkT :: (Eq a, Show b) => a -> b -> T a }}} Suppose that `v :: t` is in scope. Then the stmt {{{ MkT 1 x <- (...show v...) :: T t }}} * requires `Show t` (from the use of `show`) and `Num t` (from the literal `1`). * binds the existential `b` and constraint `Show b`. Now consider {{{ ...stmts... ApplicativeStmts [arg1, arg2, ... argN] ...more stmts... }}} where `argi :: ApplicativeArg`. Each `argi` itself contains one or more `Stmts`. It is easy to ensure that * Constraints required by the `argi` can be solved from constraint bound by `...stmts...` * Constraints and existentials bound by the `argi` are not available to solve constraints required either by `argj` (where i is different from j), or by `...more stmts...`. * Within the stmts of each `argi` individually, constraints bound by earlier stmts can be used to solve later ones. That is easy to implement and solves the immediate problem. I'm validating now. ------------------------ But the rule is terribly unsatisfactory. * To typecheck the program you must mentally desugar it into its applicative groups. * If you write {{{ MkT x1 _ <- rhs1 MkT x2 _ <- rhs2 }}} you really might intend that the `Eq t` bound by the first stmt is available to solve requirements of `rhs2`. And with normal monadic deguaring it would be, but not with `ApplicativeDo`. Worse, ''there is no way to fix it'' becuase `ApplicativeDo` works module-wide. My solution is: add syntax to allow the programmer to express the program in the form of Figure 2 of our paper, that is, post-rearrangement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 09:34:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 09:34:48 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.682aa605f1e5cdbe90656d85968b102d@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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): Simon, I also want to discuss the implementation. Look at `goArgs` in `tcApplicativeStmts`. It uses a CPS structure, so that things brought into scope stay in scope. But that's wrong for constraints (hence this ticket), and it's not really right for bindings either (only the `thing_inside` needs to see those binders). So, proposal: * Use a `mapM` to process each of the args indepdendly (mirroring the intended parallel semantics) * Now bring into scope all the variables bound by the args (which we can get from their patterns), and typecheck `thing_inside`. Can you see anything wrong with this? Should not be hard to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 09:52:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 09:52:59 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.904255ef0739642bd51216d99d1d9da5@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It is entirely unclear to me whether we should allow polymorphic static pointers. We certainly do not allow {{{ foo1 :: forall a. Num a => StaticPtr (a->a->a) foo1 = static (+) }}} so why should we allow `foo` in the `Description`? I think of the Static Pointer Table as containing `Dynamic`s: a pair of a value (just a code pointer) and a `TypeRep` describing its type. Now when we deserialise a static pointer we can (and jolly well should) do a dynamic type check. It might be possible to go further: see "Parametric polymorphism" in [wiki:StaticPointers]. But we have not even begun to implement it. So while the error message is not good, I'd like to rule out polymorphic static pointers altogether. I know that Facundo has use-cases where he wants polymorphism, but we should discuss those use-cases properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 09:53:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 09:53:22 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.421f6343374ebc7c86c3a8631effa1bd@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => StaticPointers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 09:55:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 09:55:56 -0000 Subject: [GHC] #13306: Problems with type inference for static expressions In-Reply-To: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> References: <044.f2eb8afd39f65424681365388fe1bad6@haskell.org> Message-ID: <059.16aa872910929df3450deea55ce9ca70@haskell.org> #13306: Problems with type inference for static expressions -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => StaticPointers Comment: Can you say a bit more about your use-case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 10:11:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 10:11:29 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.06adcb7b582d800e047012ad2eb827ee@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: pprIfaceCo => LevityPolymorphism Comment: OK I can reproduce this. It fails with a Lint error in the GHC 8.0 branch: {{{ *** Core Lint errors : in result of Tidy Core *** : warning: In the type ‘Unboxed x_aws[sk] -> x_aws[sk]’ Ill-kinded argument in type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ kind: TYPE (Rep x_aws[sk]) : warning: In the type ‘Unboxed x_aws[sk] -> x_aws[sk]’ Ill-kinded argument in type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ kind: TYPE (Rep x_aws[sk]) : warning: In the type ‘Unboxed x_aws[sk] -> x_aws[sk]’ Ill-kinded argument in type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ kind: TYPE (Rep x_aws[sk]) : warning: In the type ‘forall x_aws[sk]. Unbox x_aws[sk] => Unboxed x_aws[sk] -> x_aws[sk]’ Ill-kinded argument in type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ type or kind ‘Unboxed x_aws[sk] -> x_aws[sk]’ kind: TYPE (Rep x_aws[sk]) *** Offending Program *** }}} But the recent round of improvements to levity polymorphism make this OK in HEAD (and hence in 8.2). I'll add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 10:28:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 10:28:14 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.bc8dcdec51d335ddec8a81fe661f4088@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be good to get to the point where we can reproduce this. Exponential is bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:04:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:04:15 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.cd219854c61825f282943f1a59b04459@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Still reproducible in HEAD. * The reason the late demand-analysis doesn't catch it is because we don't do w/w. (Reason: see `Note [Final Demand Analyser run]` in `DmdAnal`.) * The absent argument is actually a case binder, passed as a result of `Note [Case binders and join points]` in `Simplify`. But in this case it turns out that not only is the case-binder argument eventually unused, but (even worse) every `juump` to that join point looks like `jump j x (I# x)`. So we box it, and then immediately discard it. Urk. Just recording breadcrumbs for now. My thought: never pass the case binder to a join point; instead re-box it. It's much the same trade-off as in other places where we worry about re-boxing. And it would be a lot simpler; in particular, we can stop having unfoldings in lambda-binders, which is pretty dodgy anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:20:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:20:02 -0000 Subject: [GHC] #13271: GHC Panic With Injective Type Families In-Reply-To: <050.85e94bb0ec476229be5da928608f3194@haskell.org> References: <050.85e94bb0ec476229be5da928608f3194@haskell.org> Message-ID: <065.cad84e574e2e4e8b420f873e143db426@haskell.org> #13271: GHC Panic With Injective Type Families ---------------------------------+---------------------------------------- Reporter: wayofthepie | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b125392983401cc9fe13502e52880387bc71a092/ghc" b1253929/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b125392983401cc9fe13502e52880387bc71a092" Test Trac #13271 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:20:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:20:02 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.6ce2f2d162fa7c4de2b671d94d23b1fb@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fed7136c597868d1c13b96837a2b64137a9ee65c/ghc" fed7136/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fed7136c597868d1c13b96837a2b64137a9ee65c" Test Trac #13244 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:20:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:20:02 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.5b10bac6bdbf85bde83578404f665505@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 Simon Peyton Jones ): In [changeset:"484f8d35b7cb3f77d96f9f4ffc16bb8c946f47fd/ghc" 484f8d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="484f8d35b7cb3f77d96f9f4ffc16bb8c946f47fd" Fix ApplicativeDo constraint scoping This patch fixes Trac #13242, by a bit of fancy footwork with the LIE variable in which the WantedConstraints are collected. I think it can be simplified further, using a 'map'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:21:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:21:05 -0000 Subject: [GHC] #13244: Error Dealing with Unboxed Types and Type Families In-Reply-To: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> References: <052.3ec30fc8378ee2589d04d5f3020bf145@haskell.org> Message-ID: <067.1946b2144f6fa7c9ed46e26bd6459fd8@haskell.org> #13244: Error Dealing with Unboxed Types and Type Families -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13244 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T13244 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:21:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:21:48 -0000 Subject: [GHC] #13271: GHC Panic With Injective Type Families In-Reply-To: <050.85e94bb0ec476229be5da928608f3194@haskell.org> References: <050.85e94bb0ec476229be5da928608f3194@haskell.org> Message-ID: <065.b957874dea9b4f223bec9b1ea00f84cc@haskell.org> #13271: GHC Panic With Injective Type Families -------------------------------------+------------------------------------- Reporter: wayofthepie | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T13271 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T13271 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:25:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:25:27 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.8dfb3bdb27e9f8cdf8a49703063b68b1@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 simonmar): > But the rule is terribly unsatisfactory. Yes it is. I think I'd also be fine with disabling ApplicativeDo for all statements following an existential pattern match. Or perhaps @rwbarton's suggestion: > whenever there is a pattern match that binds invisible stuff, just assume that that stuff is used in all following statements But by itself this doesn't solve the problem that the example in this ticket raises, because the A type doesn't bind any dictionaries or constraints. By all means refactor the implementation of `tcApplicativeStmts`! Provided the tests pass it should be fine. I remember trying quite hard to simplify the implementation to use fewer fresh type variables, but I couldn't figure out how to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:28:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:28:41 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.aca5dba013dfa277b67ea4474b5fcb34@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 simonmar): @simonpj Could you explain why you needed to fiddle with the LIE? I thought it would be sufficient to typecheck each statement (group) separately rather than typechecking later statements inside the scope of previous ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:36:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:36:09 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.f78dbccf208b8e84f160fb976aeeb82e@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Given that this is accepted in the current implementation: {{{ g :: Typeable a => StaticPtr (Proxy a) g = static Proxy }}} I guess that Edsko is asking to treat `foo` as if it was `g`. Which might be accomplished by just relaxing a bit the closedness check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:39:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:39:59 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.082c903931294341712f869b53f89dc9@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 thought it would be sufficient to typecheck each statement (group) separately rather than typechecking later statements inside the scope of previous ones. Yes; that's what I meant by comment:9. seems to work, and much simpler. Validating now. Re unsatisfactory nature of the current story: I'll leave it to you to document the behaviour, and perhaps improve it along the lines you suggest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 11:42:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 11:42:19 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.33373e1c83a03b9a97ed99a1e185f91e@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm surprised that is accepted, and I am no longer sure of what the specification is, or how it is implemented. (E.g. if you wrote `Num a` instead of, or as well as, `Typeable a` it would not work.) I'm quite confused. You understand all this much better than me. It would be good to nail this down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 12:36:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 12:36:56 -0000 Subject: [GHC] #13315: Compile broken on new MSYS2 In-Reply-To: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> References: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> Message-ID: <059.a2f2cbaa5ec9e49621b3ec655c56f3f5@haskell.org> #13315: Compile broken on new MSYS2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | 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 Feb 22 13:41:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:41:53 -0000 Subject: [GHC] #13316: Bad inlining cascade leads to slow optimisation Message-ID: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> #13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Consider this simple program {{{ {-# INLINE [0] f #-} f x y = case y of True -> reverse x False -> reverse (reverse x) foo a b = let x = [a,a,a,a] in f x b }}} If you compile with -DDEBUG you'll see {{{ bash$ ghc-stage1 Foo.hs -O -fforce-recomp -c WARNING: file compiler/simplCore/SimplCore.hs, line 670 Simplifier bailing out after 4 iterations [17, 1, 1, 1] Size = {terms: 60, types: 49, coercions: 0, joins: 0/0}}}} }}} Yikes! One transformation per simplifier iteration! What is going on? Before inlining `f` we have {{{ (f [a,a,a,a] b) }}} Then, we inline, beta-reduce, and build let bindings thus {{{ let x1 = a : [] x2 = a : x1 x3 = a : x2 x4 = a : x3 in case b of True -> reverse x4 False -> reverse (reverse x4) }}} So far so good. But then, bizarrely, we do `postInlineUnconditionally` on `x4` (see comments in that function). But not on `x3` because its occ- info is "once inside lambda". Then in the next iteration we `postInlineUnconditionally` `x3`, and so on. Terrible, terrible. My thought: revisit these comments in `postInlineUnconditionally`: {{{ OneOcc { occ_in_lam = in_lam, occ_int_cxt = int_cxt } -- OneOcc => no code-duplication issue -> smallEnoughToInline dflags unfolding -- Small enough to dup -- ToDo: consider discount on smallEnoughToInline if int_cxt is true -- -- NB: Do NOT inline arbitrarily big things, even if one_br is True -- Reason: doing so risks exponential behaviour. We simplify a big -- expression, inline it, and simplify it again. But if the -- very same thing happens in the big expression, we get -- exponential cost! -- PRINCIPLE: when we've already simplified an expression once, -- make sure that we only inline it if it's reasonably small. && (not in_lam || -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot- spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} What is particularly annoying in this case is that `x` is used in all code paths, so all this inlining simply duplicates code while gaining nothing. Moreover, if we had {{{ let x = blah in case y of A -> ...x... B -> ..x..x... C -> }}} then the multiple uses of `x` in the `B` branch would disable this entire `preInlineUnconditionally` thing, even though it might be a good idea to push the allocation of `x` into the `A` and `B` branches, to avoid the `C` code path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 13:48:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:48:11 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.82d21127da34e732d46a1c9c08820af0@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): I think this is simply a case of a bad error message. The error message should say that what's missing here is the `Typeable` constraint on `a`. The spec is pretty simple: parametric polymorphism is allowed, ad hoc polymorphism is not. BUT, type variables each give rise to `Typeable` constraints. So {{{#!hs :: StaticPtr (Int -> Int) -- is legal :: StaticPtr (a -> a) -- is illegal :: Num a => StaticPtr (a -> a) -- is illegal :: Typeable a => StaticPtr (a -> a) -- is legal :: Typeable a => Dict (Num a) -> StaticPtr (a -> a) -- is legal }}} This is because it doesn't make sense to point to something whose type I can't describe. And I can only describe some type `T[a,b]` if I know that `a` and `b` are `Typeable`. In the future, one might imagine that when looking up a pointer to some value `foo` in the SPT, we check that the concrete monotype at which we're doing the lookup is legit wrt the (poly)type of `foo` recorded in the SPT. The details of how this works haven't been fleshed out fully by anyone as far as I'm aware, but we at least know that this ought to be possible to do (for prenex polymorphic types) provided we have the `Typeable` dictionaries for all the type variables. Do we really need parametric polymorphism? Yes we do, I would argue. It is used quite a bit in a project like sparkle. See for example http://hackage.haskell.org/package/distributed-closure. The package defines what a `Closure` is. It says that `Closure` is a `Functor`-like thing, in that you can define {{{#!hs cmap :: ... => Closure (a -> b) -> Closure a -> Closure b }}} It is moreover a (quasi) `Applicative`-like thing, in that you can define {{{#!hs cpure :: ... => a -> Closure a cap :: ... => Closure (a -> b) -> Closure a -> Closure b }}} But surely I must be cheating. What's in the `... =>` part of the signature for `cpure`? We want something like `Serializable a =>`, because I can only lift into a closure what I know how to (de)serialize. So far so good? Now let's look at the real definition of `cpure`: {{{#!hs data Dict c = c => Dict decodeD :: Typeable a => Dict (Serializable a) -> ByteString -> a decodeD Dict = decode cpure :: Typeable a => Closure (Dict (Serializable a)) -> a -> Closure a cpure cdict x | Dict <- unclosure cdict = Closure x $ StaticPtr (static decodeD) `cap` cdict `cap` Encoded (encode x) }}} GHC doesn't currently allow me to have `Serializable a => ...` directly, but I can work around that just fine using `ConstraintKinds` and the "dict trick" (your name). Notice the `(static decodeD)`: I'm making a static pointer at a polymorphic type to `decodeD`. If I couldn't do that, then I wouldn't be able to define a combinator like `cpure` once and for all. I would need one per concrete type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 13:48:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:48:32 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.1ea3f75e9e4e7e863b60966aae281317@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 Simon Peyton Jones ): In [changeset:"254bc3357b0de673b7873f1c4cf5dfc26d0bb5f2/ghc" 254bc33/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="254bc3357b0de673b7873f1c4cf5dfc26d0bb5f2" A much nicer solution for typechecking ApplicativeDo This patch improves the code for TcMatches.tcApplicativeStmts; see the suggestion in Trac #13242 comment:9. I now use (mapM goArg args) rather than a CPS-style fold. The result is less code, easier to understand, and automatically fixes the original problem in Trac #13242. See Note [ApplicativeDo and constraints]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 13:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:53:17 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.ba29fb613d37f16c3696a7eb18ab4875@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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): Assigning to simonmar for user-manual updates; and possible further work on the design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 13:54:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:54:50 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.ded63d01385c9bba4f1e562c250b1ee1@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Nice rationale Mathieu. I concur completely :) Just wanted to say "I think this is simply a case of a bad error message" is a bit confusing. I forgot the `Typeable` annotation, but that's a bit of a red herring. What I meant to say was {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StaticPointers #-} module Main where import Data.Proxy import Data.Typeable import GHC.StaticPtr foo :: forall a. Typeable a => StaticPtr (Proxy a) foo = static (Proxy :: Proxy a) main :: IO () main = putStrLn "Hi" }}} should be accepted, but doesn't because the syntactic check is overzealous. Indeed, in my first version, if that check is relaxed, the error message should probably say `Typeable a` is missing (though see also #13306, where for `f9` the error message is confusing. Not sure what will happen.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 13:58:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:58:35 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.e587c86b7bff8e06f5c89adbe91b371c@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): > I'm surprised that is accepted, and I am no longer sure of what the specification is, or how it is implemented. (E.g. if you wrote Num a instead of, or as well as, Typeable a it would not work.) This is because the `Typeable` comes from `static` itself; we can have polymorphic static values (but they must be `Typeable`); we do not support adhoc polymorphism (and workaround this all the time using `Dict`s). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 13:59:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 13:59:34 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.d6bc8d3ce6ac7cbb7bcea5908f10dbf9@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Ah, right. So a tree was hiding the forest here. A bug within a bug. ;) Facundominguez any idea what's going on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 14:34:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 14:34:45 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.21900121b824e97fd34f43f6f5621bfa@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Core Libraries | 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: | Phab:D3019 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D1205, Phab:D3109 => Phab:D1205, Phab:D3019 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 17:03:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 17:03:49 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates In-Reply-To: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> References: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> Message-ID: <061.d648156ebd38e7341cfef534925c5207@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is no longer the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 17:48:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 17:48:30 -0000 Subject: [GHC] #13317: exprIsConApp_maybe should deal better with strings Message-ID: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> #13317: exprIsConApp_maybe should deal better with strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Consider {{{ x :: Addr# x = "foo"# y = case unpackCString# x of [] -> ... (x:xs) -> ... }}} `exprIsConApp_maybe` has a special case for literal strings; see `Note [exprIsConApp_maybe on literal strings]` in `CoreSubst`. But it only works if `unpackCString#` is applied to a literal, not to a variable bound to a literal (like `x`). The fix is easy. Instead of this code {{{ , [Lit (MachStr str)] <- args = dealWithStringLiteral fun str co }}} we want to use `exprIsLiteral_maybe`, thus {{{ , Just (MachStr str) <- exprIsLiteral_maybe ... arg = dealWithStringLiteral fun str co }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 19:43:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 19:43:44 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.abfcf3ed897ae08ac9ff6d57f5a2200b@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12863 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12863 Comment: See also #12863 for another occurrence of this design question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 19:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 19:44:02 -0000 Subject: [GHC] #12863: Associated data families don't use superclasses when deriving instances In-Reply-To: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> References: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> Message-ID: <066.2a8a11994c6f84b9247f37b0c0f451fb@haskell.org> #12863: Associated data families don't use superclasses when deriving instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4815 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #4815 Comment: I'm closing this as a duplicate of #4815, which is essentially the same thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 20:06:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 20:06:29 -0000 Subject: [GHC] #7204: Use a class to control FFI marshalling In-Reply-To: <046.b23ba7f58fad45f17252afa46fc8e205@haskell.org> References: <046.b23ba7f58fad45f17252afa46fc8e205@haskell.org> Message-ID: <061.cce7f7ec1adf8a5cc3fc2db81ecc61be@haskell.org> #7204: Use a class to control FFI marshalling -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Now that #2721/#8165 have been fixed, the technical obstacle of not being able to use `GeneralizedNewtypeDeriving` on classes with associated types is gone. The only question remaining is if we want to pursue this design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 21:48:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 21:48:38 -0000 Subject: [GHC] #13318: ghc-7.10.1 panics when compiling singletons-1.1.2.1 Message-ID: <051.fee3784b259eee823ebca2d7cf8db8a0@haskell.org> #13318: ghc-7.10.1 panics when compiling singletons-1.1.2.1 -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not sure if this has been fixed in newer versions or not, but: {{{ [39 of 45] Compiling Data.Singletons.Prelude.List ( src/Data/Singletons/Prelude/List.hs, dist/build/Data/Singletons/Prelude/List.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule n_X2iZh [a_a2gBn, t_a2gBo, n_a2iB7, ipv_s2szc, ipv_s2szd, sc_s2tXD, sc_s2tXF, sc_s2tXG, sg_s2tXH] [a_X2gZv, t_X2gZx, n_X2iZh, ipv_X2sXn, ipv_X2sXp, sc_X2ulQ, sc_X2ulT, sc_X2ulV, sg_X2ulX] [TYPE a_a2gBn, TYPE t_a2gBo, TYPE Let1627878522XsSym4 t_a2gBo n_a2iB7 ipv_s2szc ipv_s2szd, sc_s2tXD, (SCons @ a_a2gBn @ (ipv_s2szc : ipv_s2szd) @ ipv_s2szc @ ipv_s2szd @~ _N sc_s2tXF sc_s2tXG) `cast` (sg_s2tXH :: R:Sing[]z (ipv_s2szc : ipv_s2szd) ~R# Sing (Apply (Apply (:$) ipv_s2szc) ipv_s2szd))] [TYPE a_a2gBn, TYPE t_a2gBo, TYPE Let1627878522XsSym4 t_a2gBo ipv_s2szc ipv_X2sQZ ipv_X2sR1, sc_s2tXD, (SCons @ a_a2gBn @ (ipv_X2sQZ : ipv_X2sR1) @ ipv_X2sQZ @ ipv_X2sR1 @~ _N ipv_s2szf ipv_s2szg) `cast` (Sub (Sym (TFCo:R:Sing[]z[0] _N)) (Sym (TFCo:R:Apply[][]:$$l0[0] _N _N _N) ; (Apply (Sym (TFCo:R:Apply(->)k:$l0[0] _N _N)) _N)_N) :: R:Sing[]z (ipv_X2sQZ :$$$ ipv_X2sR1) ~R# Sing (Apply (Apply (:$) ipv_X2sQZ) ipv_X2sR1))] 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 Feb 22 22:52:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 22:52:11 -0000 Subject: [GHC] #13319: Generate makefile dependencies suitable for ghc --make! Message-ID: <043.6f02b27f11177631b843e2e1ee15158e@haskell.org> #13319: Generate makefile dependencies suitable for ghc --make! -------------------------------------+------------------------------------- Reporter: 1chb | Owner: (none) 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: -------------------------------------+------------------------------------- When using `ghc --make` to generate a binary, I'm interested to know what source files was used. I want that information to tell when to regenerate the binary. Yes, I use a `gmake` files to build my binaries even for `ghc` generated binaries. `gmake` is very convenient and useful as is `ghc --make`, but it is difficult to combine these two. For now, I can always call `ghc --make` but it takes extra build times. Especially when there are many binaries to build. I have considered the `-M` flag but it seems to be usable for separate compilation only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 23:30:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 23:30:00 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) Message-ID: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableInstances loop | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm afraid this will simply be seen as "that's what happens when you use UndecidableInstances", but I might as well document this issue I had. Trying to play with a "Trees that Grow" syntax, I encountered an issue when making a mistake, that can be boiled down to the following: {{{#!hs {-# language ConstraintKinds, FlexibleContexts, TypeFamilies, UndecidableInstances #-} module Loop where import GHC.Exts (Constraint) import Test.QuickCheck type family X_Var ξ data TermX ξ = Var (X_Var ξ) type ForallX (φ :: * -> Constraint) ξ = ( φ (X_Var ξ) ) --genTerm :: ForallX Arbitrary ξ => Int -> Gen (TermX ξ) genTerm 0 = Var <$> arbitrary genTerm n = Var <$> genTerm (n - 1) --instance ForallX Arbitrary ξ => Arbitrary (TermX ξ) where --arbitrary = sized genTerm }}} This code will compile correctly, and generate: {{{#!hs genTerm :: (X_Var ξ ~ TermX ξ, Arbitrary (TermX ξ), Eq t, Num t) => t -> Gen (TermX ξ) }}} Which is correct (though, not the type I had intended, since my code had a mistake). Now, if you uncomment the "instance" line only, the compiler will loop. Adding the commented out type, of course, gives a type error where it's due. I was just wondering whether this type of error failed with the loops that should be caught by the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 23:37:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 23:37:18 -0000 Subject: [GHC] #13318: ghc-7.10.1 panics when compiling singletons-1.1.2.1 In-Reply-To: <051.fee3784b259eee823ebca2d7cf8db8a0@haskell.org> References: <051.fee3784b259eee823ebca2d7cf8db8a0@haskell.org> Message-ID: <066.85d3ef1213a0687796895610eab21e74@haskell.org> #13318: ghc-7.10.1 panics when compiling singletons-1.1.2.1 -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10689 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #10689 Comment: This is a duplicate of #10689, which was fixed in GHC 7.10.3. (I've also confirmed locally that `singletons-1.1.2.1` builds without issue using 7.10.3.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 23:48:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 23:48:22 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.15b68ea7db9b928291fbac1486342322@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableInstances loop Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a version with no dependencies: {{{#!hs {-# language ConstraintKinds, FlexibleContexts, TypeFamilies, UndecidableInstances #-} module Loop where import GHC.Exts (Constraint) data QCGen newtype Gen a = MkGen { unGen :: QCGen -> Int -> a } sized :: (Int -> Gen a) -> Gen a sized f = MkGen (\r n -> let MkGen m = f n in m r n) class Arbitrary a where arbitrary :: Gen a type family X_Var ξ data TermX ξ = Var (X_Var ξ) type ForallX (φ :: * -> Constraint) ξ = ( φ (X_Var ξ) ) -- Uncommenting the line below gives a proper type error. --genTerm :: ForallX Arbitrary ξ => Int -> Gen (TermX ξ) genTerm 0 = Var <$> arbitrary genTerm n = Var <$> genTerm (n - 1) instance ForallX Arbitrary ξ => Arbitrary (TermX ξ) where arbitrary = sized genTerm }}} At the very least, compiling this on GHC HEAD doesn't loop forever, but instead fails with a stack overflow: {{{ Bug.hs:25:1: error: Reduction stack overflow; size = 201 When simplifying the following type: Arbitrary (TermX ξ0) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) | 25 | genTerm 0 = Var <$> arbitrary | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 22 23:51:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Feb 2017 23:51:28 -0000 Subject: [GHC] #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) In-Reply-To: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> References: <045.270af171407ac82a7e1d299a1767fa44@haskell.org> Message-ID: <060.25976d9ffa5f138b1c4d577b72c229dd@haskell.org> #13320: Unfortunate compiler loop when creating type loop (with UndecidableInstances) -------------------------------------+------------------------------------- Reporter: Ptival | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | UndecidableInstances loop Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Ptival: Old description: > I'm afraid this will simply be seen as "that's what happens when you use > UndecidableInstances", but I might as well document this issue I had. > > Trying to play with a "Trees that Grow" syntax, I encountered an issue > when making a mistake, that can be boiled down to the following: > > {{{#!hs > {-# language ConstraintKinds, FlexibleContexts, TypeFamilies, > UndecidableInstances #-} > > module Loop where > > import GHC.Exts (Constraint) > import Test.QuickCheck > > type family X_Var ξ > > data TermX ξ = Var (X_Var ξ) > > type ForallX (φ :: * -> Constraint) ξ = ( φ (X_Var ξ) ) > > --genTerm :: ForallX Arbitrary ξ => Int -> Gen (TermX ξ) > genTerm 0 = Var <$> arbitrary > genTerm n = Var <$> genTerm (n - 1) > > --instance ForallX Arbitrary ξ => Arbitrary (TermX ξ) where > --arbitrary = sized genTerm > > }}} > > This code will compile correctly, and generate: > > {{{#!hs > genTerm :: (X_Var ξ ~ TermX ξ, Arbitrary (TermX ξ), Eq t, Num t) => t -> > Gen (TermX ξ) > }}} > > Which is correct (though, not the type I had intended, since my code had > a mistake). > > Now, if you uncomment the "instance" line only, the compiler will loop. > > Adding the commented out type, of course, gives a type error where it's > due. > > I was just wondering whether this type of error failed with the loops > that should be caught by the compiler. New description: I'm afraid this will simply be seen as "that's what happens when you use UndecidableInstances", but I might as well document this issue I had. Trying to play with a "Trees that Grow" syntax, I encountered an issue when making a mistake, that can be boiled down to the following: {{{#!hs {-# language ConstraintKinds, FlexibleContexts, TypeFamilies, UndecidableInstances #-} module Loop where import GHC.Exts (Constraint) import Test.QuickCheck type family X_Var ξ data TermX ξ = Var (X_Var ξ) type ForallX (φ :: * -> Constraint) ξ = ( φ (X_Var ξ) ) --genTerm :: ForallX Arbitrary ξ => Int -> Gen (TermX ξ) genTerm 0 = Var <$> arbitrary genTerm n = Var <$> genTerm (n - 1) --instance ForallX Arbitrary ξ => Arbitrary (TermX ξ) where --arbitrary = sized genTerm }}} This code will compile correctly, and generate: {{{#!hs genTerm :: (X_Var ξ ~ TermX ξ, Arbitrary (TermX ξ), Eq t, Num t) => t -> Gen (TermX ξ) }}} Which is correct (though, not the type I had intended, since my code had a mistake). Now, if you uncomment the "instance" line only, the compiler will loop. Adding the commented out type, of course, gives a type error where it's due. I was just wondering whether this type of error fell within the "loops that should be caught by the compiler". -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 00:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 00:58:56 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.61eaa7ba412f3579be4feeceadbb0de7@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Relaxing the closedness check to not require the body of the static form to be typed-closed gets this test passing. Now I'm trying to recall why we wanted it to be type-closed to begin with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 01:38:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 01:38:25 -0000 Subject: [GHC] #13321: Importing a bundled pattern "infects" all other imports of that pattern Message-ID: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> #13321: Importing a bundled pattern "infects" all other imports of that pattern -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider: {{{ {-# LANGUAGE PatternSynonyms #-} unit p where module A0 where data G = G Int module A1 where import A0 pattern X x = G x module A(G(X)) where import A0 import A1 module B(G) where import A module C(pattern X) where import A module D(N.G, pattern N.X) where import B import C import qualified A0 as N import qualified A1 as N }}} When we look at the interface for D, we see that N is bundled with D. This is a little surprising because I explicitly exported the G and X from A0 and A1, where no bundling took place. I suppose the current semantics might also be alright, but we should explicitly say so. The spec in the wiki is silent in this respect: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/AssociatingSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 02:27:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 02:27:40 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.4d023809fa58a97bf73105a0eb9dd1aa@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 02:41:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 02:41:52 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.005cf0a55fa2e190adf5e5616220286b@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Here is a bad example: {{{ foo :: forall a. (Typeable a, Num a) => StaticPtr a foo = static g where g = 0 :: a }}} If we allow the type of `g` to be "open", the static form becomes invalid because `g` refers to a `Num a` instance only known when `foo` is called. Therefore, by asking the type-closedness we reject programs like {{{ foo :: forall a. Typeable a => StaticPtr (Proxy a) foo = static g where g = Proxy :: Proxy a }}} which would be harmless. Now, the good news is that ghc HEAD accepts Edsko's program, which results from inlining `g`: {{{ foo :: forall a. Typeable a => StaticPtr (Proxy a) foo = static (Proxy :: Proxy a) }}} because type-closedness is only demanded of the identifiers referred to in the body of the static form, but the body itself can have an "open" type. Isn't this a bug? What if we bring `Num a` again: {{{ foo :: forall a. (Typeable a, Num a) => StaticPtr a foo = static (0 :: a) }}} The compiler will reject the program because the body of the static form requires a `Num a` instance which is not in the context. So we are safe. I couldn't be sure, but I'm more inclined to think that the current (hopefully correct) implementation is more of an accident than a designed behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 04:01:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 04:01:59 -0000 Subject: [GHC] #13236: Improve floating for join points In-Reply-To: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> References: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> Message-ID: <061.8328c28b423f2bdb042debfc7afdda37@haskell.org> #13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): Yes, that's similar to the example in `FloatOut` with nested loops---which came directly from list-fusion code (filter of filter of filter). Floating to make things trivial (as the Simplifier does) is less important than floating to share computation, but it can be significant. (And the Simplifier can't do the floating in this case because it doesn't realize that `j2` doesn't refer to `y`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 04:03:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 04:03:25 -0000 Subject: [GHC] #13250: Backpack: matching newtype selectors doesn't work In-Reply-To: <045.0e7a960652fd03d6405838b3d76bce63@haskell.org> References: <045.0e7a960652fd03d6405838b3d76bce63@haskell.org> Message-ID: <060.962ed4c79707313b7a626f5650b1f98a@haskell.org> #13250: Backpack: matching newtype selectors doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: backpack 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 ezyang): * status: new => closed * resolution: => duplicate Comment: This is caused by #12699. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 04:49:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 04:49:42 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.67c3be6aafe815698daeda5babbcb029@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3174 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3174 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 05:07:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 05:07:48 -0000 Subject: [GHC] #13322: Pattern synonyms in hs-boot files Message-ID: <045.6b7aa07fdcb8793a715c6f96fb599d5e@haskell.org> #13322: Pattern synonyms in hs-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Pattern synonyms are not permitted in hs-boot files: {{{ ezyang at sabre:~/bun$ ghc-head -c A.hs-boot A.hs-boot:3:5: error: Misplaced pattern synonym signature: pattern X :: Bool | 3 | pattern X :: Bool | ^^^^^^^^^^^^^^^^^ A.hs-boot:3:13: error: The pattern synonym signature for ‘X’ lacks an accompanying binding | 3 | pattern X :: Bool | }}} There isn't really any reason why they shouldn't be supported. One thing to check closely: if we bundle a pattern synonym declared in an hs-boot file with another type, in an hs-boot file, what happens? In particular, does an hs file which doesn't bundle the pattern synonym and the type valid? If we add support for them, make sure that Backpack signatures handle it properly. In particular, suppose we have: {{{ signature A(T(X)) where data T pattern X :: T }}} Then, when we instantiate A, we must be careful to NOT blindly reuse the implementing module of T for X (as we do today in `uAvailInfo` in `NameShape`), since T and X may be defined in different modules. I'm not likely to implement this unless someone asks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 05:18:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 05:18:35 -0000 Subject: [GHC] #13323: Backpack doesn't work with DuplicateRecordFields Message-ID: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> #13323: Backpack doesn't work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: backpack | 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 {{{ {-# LANGUAGE DuplicateRecordFields #-} unit p where signature A where data A = A { foo :: Int } data B = B { foo :: Bool } }}} I get: {{{ [1 of 1] Processing p [1 of 1] Compiling A[sig] ( p/A.hsig, nothing ) : error: The identifier $sel:foo:A does not exist in the local signature. (Try adding it to the export list of the hsig file.) }}} This is happening because the "exports" test is checking only the children of AvailTC, and not the field labels. Should be an easy fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 06:01:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 06:01:15 -0000 Subject: [GHC] #13323: Backpack doesn't work with DuplicateRecordFields In-Reply-To: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> References: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> Message-ID: <060.a485addb1edaae52d9d60fadb013def5@haskell.org> #13323: Backpack doesn't work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3175 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3175 * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 08:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 08:41:32 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.6bbacd81941c7e5015bae735ebb0f626@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3174 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: adamgundry => ezyang Comment: Thanks very much for sorting this out! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 09:59:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 09:59:22 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.c7efbc744e8de10f36a762da5ff8b11a@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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 simonmar): @simonpj, so the new code doesn't bring constraints into scope from existential bindings, even in statements that sequentially follow the existential pattern match. e.g. {{{ Prelude> data T where A :: forall a . Eq a => a -> T Prelude> :set -XApplicativeDo Prelude> do { A x <- undefined; y <- return (); return (x == x) } :7:48: error: • Could not deduce (Eq a) arising from a use of ‘==’ from the context: Monad f bound by the inferred type of it :: Monad f => f Bool at :7:1-56 Possible fix: add (Eq a) to the context of the inferred type of it :: Monad f => f Bool • In a stmt of a 'do' block: return (x == x) In the expression: do A x <- undefined y <- return () return (x == x) In an equation for ‘it’: it = do A x <- undefined y <- return () return (x == x) }}} I understand why - because the implementation specifically only binds Ids - but it's somewhat surprising. Is this fixable, or should I try to document it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 10:00:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 10:00:59 -0000 Subject: [GHC] #13315: Compile broken on new MSYS2 In-Reply-To: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> References: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> Message-ID: <059.70e5d5b593f936b79cb1598f84392e72@haskell.org> #13315: Compile broken on new MSYS2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => upstream Comment: https://github.com/Alexpux/MSYS2-packages/issues/822 The solution above is only partial. pipes are still affected by this change in behaviour and there's no way to correct those without inserting `dos2unix` calls between the pipes. This is a non-starter. The above changes are enough to build GHC again, just seems not enough to be able to run `nofib`. The best solution is for the `MSYS2` project to revert these `Cygwin` patches in the distro. As they're not the expected behaviour for Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 10:26:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 10:26:36 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.4f0cf97c73ff54d345fa9a4d0bfffde5@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): On SPJ's request: here are concrete examples showing that no choice of existing role is suitable for being "abstract": * Suppose we pick `nominal` to be abstract. Let `T` be `nominal` in its first argument: if we have `T a ~R T b`, we can derive `a ~N b`. Now set `T` to `phantom`, then we have `Int ~P Bool` and consequently `T Int ~R T Bool`. This lets us derive `Int ~N Bool`, bad! * Suppose we pick `phantom` to be abstract. Let `T` be `phantom` in its first argument: then we have `T Int ~R T Bool` for all a and b. Now set `T` to `nominal`; if `T a ~R T b`, then `a ~N b`; thus we have `Int ~N Bool`. Bad! * Suppose we pick `representational` to be abstract. Let `T` be `representational` in its first argument: then we have that if `T a ~R T b`, then `a ~R b`. Now set `T` to `phantom`, then we have `Int ~P Bool` and consequently `T Int ~R T Bool`. But this implies `Int ~R Bool`, bad! (You can also do the other proof on this one.) Another question was this: why doesn't subroling break this way? Subroling says that if we have a type variable `a` at some role ρ, we can use it at role ρ' so long as ρ <= ρ'. (N is a subrole of everything). So for example, the following is acceptable: {{{ data T a = MkT a type role S nominal data S a = MkS (T a) }}} In S, a is at role nominal, but we can pass it to a T which has a at role representational. What we are afraid of is having `T a ~R T b` imply `a ~N b` by using S. But from the hypothesis we get is `a ~R b`, which does NOT imply `S a ~R S b` (S is nominal!). Another interesting observation is how we treat a polymorphic type constructor, e.g., m in `forall m. m a -> m a`. Via the Co_App rule, to show `m a ~ρ m' b` we must show `m ~N m'` and `a ~ρ b` (like the nominal role). Via the Co_Left rules, we can only say `a ~N b` if `m a ~N m' b` (just like the phantom role, we learn nothing when `m a ~R m' b`). So the "abstract" role implicitly falls out of the way the coercion formation rules handle type variables! All of this seems like evidence that adding an abstract role annotation is "the right thing to do." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 10:56:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 10:56:36 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.f336b3bf287a40d71187d3c590b1cf88@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.3 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): > Is this fixable, or should I try to document it? The latter I think. It's hard to fix: just try to write the desugaring!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 12:25:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 12:25:23 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.c0ddb829f36ad4ca89140bfe483827b0@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 13:36:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 13:36:41 -0000 Subject: [GHC] #13321: Importing a bundled pattern "infects" all other imports of that pattern In-Reply-To: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> References: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> Message-ID: <060.5ea8f3135bf95db0fceb7b33041eead0@haskell.org> #13321: Importing a bundled pattern "infects" all other imports of that pattern -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't really understand this example sorry. What is a `unit`? How can `N` be bundled with anything (it isn't a pattern synonym)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 14:03:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 14:03:28 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.fafb4d1c6463cc9644ee8904f02bde23@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | 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 RyanGlScott): * milestone: => 8.4.1 Comment: Another thing that standalone `DeriveAnyClass` currently doesn't allow (but bare instances do) is the use of nullary classes. That is, this is allowed: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module Allowed where class C instance C }}} but this is not: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE StandaloneDeriving #-} module Bug where class C deriving instance C }}} {{{ Bug.hs:7:1: error: • Cannot derive instances for nullary classes • In the stand-alone deriving instance for ‘C’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 14:46:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 14:46:16 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.3c6cb65b87192505ff5c48297c7f8b64@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Simon, see the `bad.hs` attached. I can see the expontential behaviour with current `HEAD` too. Remember to use `-O2`. {{{ time .../bin/ghc-stage2 -O2 -fforce-recomp bad.hs # 38sec time .../bin/ghc-stage2 -O2 -fforce-recomp -DBIG bad.hs # 3min 16sec time .../bin/ghc-stage2 -O1 -fforce-recomp bad.hs # 9.8sec time .../bin/ghc-stage2 -O1 -fforce-recomp -DBIG bad.hs # 9.9sec }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 14:48:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 14:48:03 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.03cf48924cf9e41adf4c5b7718e5fe97@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto 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) Comment: I'm chiming in on this ticket pretty late, but nevertheless, here's my take on this situation. I agree that this feature shouldn't be baked into the language, and this should ideally be something that Template Haskell could handle. And Song certainly tried to make it work in TH, but quickly discovered a problem that has bitten `singletons` and many other TH libraries—TH is just plain terrible at type inference. Stated in a more focused way, if you are trying to use TH to splice in something like: {{{#!hs deriving instance ??? => C (T a b c) }}} Then trying to use TH to come up with `???` is really hard in the general case. In fact, I don't think there'd be any way to Do It Right without the full power of GHC's type inference engine, which is certainly something I'm not eager to bake into TH. I talked to Song about this at ICFP 2016, and we brainstormed some ways to get around the second point. I pointed out that `StandaloneDeriving` currently has a glaring flaw. While `StandaloneDeriving` is quite flexible and lets you derive instances wherever you want, it always requires that you provide the instance context in full. But `deriving` clauses don't have this onerous restriction, as you can just type: {{{#!hs data T a b c = ... deriving C }}} And GHC will figure out the instance context for you. What I feel like we need here is the ability to combine `StandaloneDeriving`'s capability to be used anywhere with `deriving` clauses' type inference. So what I will suggest (and hopefully articulate later in a proper GHC proposal) is extending `StandaloneDeriving` in the following way: if you type this: {{{#!hs deriving instance => C (T a b c) }}} Then GHC will try to fill in the instance context as if you had written `data T a b c = ... deriving C`. (Syntax bikeshedding is welcome.) Now the `derive-topdown` library's job is much easier: it just has to splice in a bunch of instances of the form: {{{#!hs deriving instance => Generic (A a b) deriving instance => Data (B a b) -- etc. }}} And GHC will do the rest! This requires very little in the way of fancy TH footwork, and moreover, it makes `StandaloneDeriving` more convenient to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:19:41 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.05ee1b837a10f488d9810efc6f6bd77b@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: 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): Sounds reasonable. > (Syntax bikeshedding is welcome.) Well, since you asked... how about `deriving instance _ => C (T a b c)`, which is currently accepted by the parser (and probably won't be too taxing for other tools) but rejected later with the error {{{ C.hs:8:19: error: Wildcard ‘_’ not allowed in In a deriving declaration for ‘C’ | 8 | deriving instance _ => C (T a b c) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:24:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:24:18 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.8827414f276356a3c57134de81d9d767@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm quite reluctant to steal wildcard syntax for this particular purpose, because it's conceivable that in the future, we might want to allow GHC to fill in this wildcard, producing an error to the effect of: {{{ • Found type wildcard ‘_’ standing for ‘(C a, C b, C c)’ To use the inferred type, enable PartialTypeSignatures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:24:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:24:53 -0000 Subject: [GHC] #13321: Importing a bundled pattern "infects" all other imports of that pattern In-Reply-To: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> References: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> Message-ID: <060.5b16e48c7fa93a057362f9fcc7521afc@haskell.org> #13321: Importing a bundled pattern "infects" all other imports of that pattern -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:1 mpickering]: > What is a `unit`? A backpack thing. You can save this source as a single file `U.bkp` and build it with `ghc --backpack U.bkp`. In this case it's equivalent to just writing six `.hs` files. (I just learned about this from this ticket.) > How can `N` be bundled with anything (it isn't a pattern synonym)? It should read "When we look at the interface for D, we see that X is bundled with G", I assume. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:25:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:25:25 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.116282e5711bb4e4f9baf60fb0c83b37@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: 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): Why isn't that the same thing though? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:35:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:35:09 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.0a69d58ea65f1d6d9c93054fc221ece9@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: 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): Hm... you know, that's a good observation. This approach does require another language extension (`PartialTypeSignatures`), but it certainly achieves the same end result. My only hesitation is that I don't understand `PartialTypeSignatures` that well, so I haven't fully considered the ramifications of allowing this. I'm fairly sure it would require a more complication implementation, since you'd also probably want to allow things like this: {{{#!hs deriving instance (C a, _) => C (T a b c) }}} But the prospect of not needing any changes to the language is a mighty tempting one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:37:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:37:37 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.293622337fee43480ff2ee7f1b30e8a8@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: 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): Smells right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:53:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:53:09 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration Message-ID: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use a wildcard anywhere in an instance context, it will fail immediately: {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> instance _ => Show (Maybe a) :1:10: error: Wildcard ‘_’ not allowed in an instance declaration for ‘Show’ }}} But there's one situation where we could lift this restriction: the context of a standalone, derived instance declaration. That is, something like this: {{{#!hs deriving instance _ => Show (Maybe a) }}} Why? Because GHC already has the machinery needed to infer what the context should be (see [http://git.haskell.org/ghc.git/blob/8a6b8c5fb96472d7c2e2cd1918950dd50f2fef71:/compiler/typecheck/TcDerivInfer.hs#l49 this part] of `TcDerivInfer`), so if a user turned on `PartialTypeSignatures`, GHC could just fill in the wildcard with the inferred constraints. The implementation won't be //that// easy, however, since we'd also have to watch out for trickery such as: {{{#!hs deriving instance (C a, _) => C (T a b c) }}} I only mentioned putting wildcards in a derived instance //context//, because I think allowing the use of wildcards elsewhere in the instance head might be too difficult to deal with. I mean, how would you fill in this, for example? {{{#!hs instance (_ a) }}} This mini-feature has a very practical application: it would allow users to wield the flexibility of `StandaloneDeriving` without having to manually type in the instance context every time. That is, users could type in these instances: {{{#!hs deriving instance _ => Data (T a b c) deriving instance _ => Eq (T a b c) }}} Instead of their fully spelled-out, more laborious counterparts. This would be crucial for Template Haskell, as its ability to infer these contexts is quite limited (see #10607 for an example where this cropped up). Idle thought: could this be generalized to work for the instance context of //any// instance declaration (and not just derived ones)? From an outside perspective, it seems like typechecking other instances would require inferring constraints in a fashion quite similar to that of derived instances. But I am not at all familiar with that part of the typechecker, so I might be totally off here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 15:54:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 15:54:43 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.86374ca843473edae68cfac82e37e50e@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13324 Comment: Alright. I've opened up #13324 to track the feature request for using type wildcards in derived instance contexts, since that has applications besides `derive-topdown`. Song, would this approach work for your needs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 16:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 16:21:28 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.1104f4b3ecf37097888901afbd92b9e3@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): We should make sure to watch out for these two corner cases: * Exotic constraints. Currently, trying to derive `Eq` like this: {{{#!hs newtype Foo f a = Foo (f (f a)) deriving Eq }}} Will be rejected with an error message saying: {{{ • No instance for (Eq (f (f a))) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself }}} That is, GHC will not put `Eq (f (f a))` into the set of inferred constraints because it is too "exotic". But presumably, we want a similar failure if the user instead typed this: {{{#!hs newtype Foo f a = Foo (f (f a)) deriving instance _ => Eq (Foo f a) }}} Since it's morally equivalent to just using a `deriving Eq` clause. * GADTs. GHC chooses not to even make an attempt if you try to stock- derive certain instances for GADTs with a `deriving` clause. For instance, this: {{{#!hs data T a where MkT :: T Int deriving Eq }}} is rejected with: {{{ • Can't make a derived instance of ‘Eq (T a)’: Constructor ‘MkT’ has existentials or constraints in its type Possible fix: use a standalone deriving declaration instead • In the data declaration for ‘T’ }}} So as a consequence, we should probably disallow this as well: {{{#!hs data T a where MkT :: T Int deriving instance _ => Eq (T a) }}} Notice that in both cases, the error message suggests trying a standalone deriving declaration! Obviously, we shouldn't do that if a user tries the equivalent, standalone approach with wildcards, so we should come up with a more appropriate error message for this scenario. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 16:37:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 16:37:54 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... In-Reply-To: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> References: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> Message-ID: <065.dea50e9957111961eafac62356a54655@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12808 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like anything will happen on this for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 17:02:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 17:02:41 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.52b47937fba19a5cea714b95ce706e66@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Since it's morally equivalent to just using a deriving Eq clause. And it'll be implementationally the same as using `deriving Eq` too! So the same things will happen automatically. In the code, the `mtheta` variable will tbe `Nothing` rather than `Just`. Just allowing a wildcard on its own would be a good start. But we have code for doing the "subtraction" in cases like `(Eq a, _) => blah`, so it would not be too hard to support that too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 17:36:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 17:36:57 -0000 Subject: [GHC] #13325: Binary distributions produced from cross-compiled stage2 are broken Message-ID: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> #13325: Binary distributions produced from cross-compiled stage2 are broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8910 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The binary distribution by a cross-compiled build (e.g. configure with `./configure --target=$cross_target`) is broken out of the box. After untarring and configuring the bindist, `make install` fails due to missing files, {{{ # make install make --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES ghc.mk:742: utils/ghctags/ghc.mk: No such file or directory ghc.mk:742: utils/check-api-annotations/ghc.mk: No such file or directory ghc.mk:742: utils/check-ppr/ghc.mk: No such file or directory make[1]: *** No rule to make target 'utils/check-ppr/ghc.mk'. Stop. Makefile:51: recipe for target 'install' failed make: *** [install] Error 2 }}} This can be worked around by, {{{ $ mkdir utils/ghctags utils/check-ppr utils/check-api-annotations $ touch utils/hp2ps/dist/build/tmp/hp2ps \ utils/ghctags/ghc.mk \ utils/check-api-annotations/ghc.mk \ utils/check-ppr/ghc.mk }}} I believe the reason for this is that these are utilities which would typically be built by the stage2 compiler, which we obviously are unable to build. There are a few options for fixing this, * Produce a shell script throwing an error to sit in place of the unbuildable utilities * Fix the build system to include the appropriate `ghc.mk` files in the bindist, despite the utilities they build not being present * Include the sources for the utilities in the bindist and teach `make install` to build them -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 18:28:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 18:28:02 -0000 Subject: [GHC] Trac email verification for user: coopercm Message-ID: <20170223182802.A13233A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: coopercm Verification Token: Qtp3pZ4U -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 18:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 18:29:43 -0000 Subject: [GHC] #13307: Record pattern synonym fields have to be manually exported In-Reply-To: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> References: <047.977638e1bfaa3ec282425be0d9a19203@haskell.org> Message-ID: <062.7f7dbaea34e437eb79b70aa65077c8ab@haskell.org> #13307: Record pattern synonym fields have to be manually exported -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- Changes (by mnislaih): * cc: mnislaih (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 18:33:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 18:33:42 -0000 Subject: [GHC] #13326: Implement `-ferror-limit` for GHC Message-ID: <047.99e5f0e5b0cd996428b6bbf87ebc89d6@haskell.org> #13326: Implement `-ferror-limit` for GHC -------------------------------------+------------------------------------- Reporter: coopercm | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Clang has an option `-ferror-limit=n` which is very handy for development since it lets you focus on the first error message when there is a long list of errors. A similar flag for GHC would be very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 18:57:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 18:57:50 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.101a1744ea5bf0fb9e467d262fa98dfb@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I'm 99% certain this was resolved by bbd3c399939311ec3e308721ab87ca6b9443f358. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 19:02:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 19:02:16 -0000 Subject: [GHC] #12413: Compact regions support needs some discussion in the release notes In-Reply-To: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> References: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> Message-ID: <061.7ded2fb4faaf8aca09e50431957fc0a2@haskell.org> #12413: Compact regions support needs some discussion in the release notes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Documentation | Version: 8.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 bgamari): * status: new => closed * resolution: => fixed Comment: This was taken care of in e7e5f7accbb7d9a12aee5d1468371a8ba09b598d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 19:02:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 19:02:45 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.5e3316185e5aeaee64a0d60d9d4dbcae@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Looks like we won't be looking into this for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 19:38:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 19:38:40 -0000 Subject: [GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes Message-ID: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> #13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4028 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something's funny with `Data.Data`. In particular, what instance do you expect when you write this? {{{#!hs data T phantom = T deriving Data }}} You might expect: {{{#!hs instance Typeable phantom => Data (T phantom) where ... }}} And indeed, it is possible to define a `Data` instance like this. But in practice, GHC actually derives this instance: {{{#!hs instance Data phantom => Data (T phantom) where ... dataCast1 f = gcast1 f }}} The reason is because GHC has special cases for when it derives `Data` instances for datatypes of kind `* -> *` or `* -> * -> *`. These special cases cause the derived `Data` instances to insert definitions for `dataCast1` or `dataCast2`, respectively, and their implementations (`gcast1` or `gcast2`, respectively) require the stronger instance context. See #4028 for a longer discussion about this. Things get far less predictable when you throw in `PolyKinds`, however. If you try this instead: {{{#!hs data T (phantom :: k) = T deriving Data }}} Then you do //not// get `instance Data phantom => Data (T phantom)` as above. Instead, you get this: {{{#!hs instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where ... -- No implementation for dataCast1 }}} As it turns out, GHC's special-casing for deriving `Data` is not privy to datatypes of kind `k -> *` or `k1 -> k2 -> *`, just `* -> *` and `* -> * -> *`. This is all a bit disconcerting because if you look at `Data.Data`, there are many instances of the flavor: {{{#!hs deriving instance Data (p :: *) => Data (U1 p) -- U1 :: k -> * }}} This makes sense in a pre-`PolyKinds` world, but really, the most general type for this `Data` instance would be: {{{#!hs deriving instance (Typeable k, Typeable (p :: k)) => Data (U1 p) }}} Even worse, choosing the less polymorphic instance `Data (p :: *) => Data (U1 p)` via `StandaloneDeriving` doesn't even cause GHC to emit a definition for `dataCast1`—it just restricts the kind with no benefit! This whole situation doesn't sit well with me, especially since as we add more poly-kinded `Data` instances to `Data.Data`, we have to ask ourselves each time what the "right" `Data` instance is. It would be great if we could answer these questions: 1. Should we expand the special-casing for datatypes of kind `k -> *` or `k1 -> k2 -> *`? Or do `dataCast1` and `dataCast2` even make sense for poly-kinded datatypes? 2. Is there a way to modify `DeriveDataTypeable` such that emitting definitions for `dataCast1` and `dataCast2` don't require us to default some kind variables to `*`? Perhaps `TypeInType` could help us here somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 21:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 21:39:23 -0000 Subject: [GHC] #13321: Importing a bundled pattern "infects" all other imports of that pattern In-Reply-To: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> References: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> Message-ID: <060.19ec76dd7f7cd942e3e5b9a7a510c83c@haskell.org> #13321: Importing a bundled pattern "infects" all other imports of that pattern -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Yes, rwbarton is exactly right. Here's a self-contained example that doesn't involve looking at the interface file: {{{ {-# LANGUAGE PatternSynonyms #-} unit p where module A0 where data G = G Int module A1 where import A0 pattern X x = G x module A(G(X)) where import A0 import A1 module B(G) where import A module C(pattern X) where import A module D(N.G, pattern N.X) where import B import C import qualified A0 as N import qualified A1 as N module E where import D(G(..)) f (X x) = x -- X is in scope }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 21:42:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 21:42:44 -0000 Subject: [GHC] #13321: Importing a bundled pattern "infects" all other imports of that pattern In-Reply-To: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> References: <045.4cdfb2ebba49e75e48601bfc9abba1b6@haskell.org> Message-ID: <060.8e6c86c5a97bde0e60a51858598cc341@haskell.org> #13321: Importing a bundled pattern "infects" all other imports of that pattern -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Consider: > > {{{ > {-# LANGUAGE PatternSynonyms #-} > unit p where > module A0 where > data G = G Int > module A1 where > import A0 > pattern X x = G x > module A(G(X)) where > import A0 > import A1 > module B(G) where > import A > module C(pattern X) where > import A > module D(N.G, pattern N.X) where > import B > import C > import qualified A0 as N > import qualified A1 as N > }}} > > When we look at the interface for D, we see that N is bundled with D. > This is a little surprising because I explicitly exported the G and X > from A0 and A1, where no bundling took place. > > I suppose the current semantics might also be alright, but we should > explicitly say so. The spec in the wiki is silent in this respect: > https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/AssociatingSynonyms New description: Consider: {{{ {-# LANGUAGE PatternSynonyms #-} unit p where module A0 where data G = G Int module A1 where import A0 pattern X x = G x module A(G(X)) where import A0 import A1 module B(G) where import A module C(pattern X) where import A module D(N.G, pattern N.X) where import B import C import qualified A0 as N import qualified A1 as N }}} When we look at the interface for D, we see that X is bundled with G. This is a little surprising because I explicitly exported the G and X from A0 and A1, where no bundling took place. I suppose the current semantics might also be alright, but we should explicitly say so. The spec in the wiki is silent in this respect: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/AssociatingSynonyms -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 22:26:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 22:26:58 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries In-Reply-To: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> References: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> Message-ID: <061.7ab3c032a8732e903c8212e8950174c0@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7d116e553f0b44723e279ae5affa744e6aefc3c0/ghc" 7d116e55/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7d116e553f0b44723e279ae5affa744e6aefc3c0" rts: Correct the nursery size in the gen 1 growth computation Fixes trac issue #13288. Reviewers: austin, bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: mutjida, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3143 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 22:26:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 22:26:58 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.bbbcab4742ac73df51abf23d650f2b37@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T13287 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3147 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6ca6a360c2b71d7e0c77a819dc463b37efe7a39d/ghc" 6ca6a36/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6ca6a360c2b71d7e0c77a819dc463b37efe7a39d" base: Add handling of -- to getArgs for Windows getArgs didn't match the treatmeant of -- in the RTS leading to inconsistencies between behavior on Windows and other platforms. See #13287. Reviewers: austin, hvr, bgamari, erikd, simonmar, rwbarton Reviewed By: bgamari, rwbarton Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3147 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 22:30:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 22:30:21 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.11817bf33af145a347343d2b7eb16135@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The Right Thing to do is to go back in time and erase the idea of roles from our brains... and reimplement `GeneralizedNewtypeDeriving` in terms of a generated blob of source code that gets type-checked (instead of the magical implementation it used to have). Barring that, I can't find an argument against a new abstract role other than to harrumph as loudly as I can. Harrumph! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 22:40:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 22:40:59 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries In-Reply-To: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> References: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> Message-ID: <061.9f3d8f59552d61ce5c4dedfcaa198c50@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Comment (by j6carey): Thank you for committing this fix. We still see RSS growth beyond the -M limit, but that is due to having a large number of partially-used megablocks involved in the free block group list. They cannot be returned to the operating system because they are still partly in use, and yet their free space is not counted as heap size, and therefore is not limited by -M. We have not yet figured out why there is such high fragmentation in our application. But clearly that is a distinct issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:06:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:06:27 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly Message-ID: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: deriving-perf | 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: -------------------------------------+------------------------------------- Suppose we have {{{#!hs data Phantom a = Z | S (Phantom a) }}} We'd like to get something like {{{#!hs foldMap _ _ = mempty fmap = coerce traverse _ m = pure (coerce m) }}} But instead we actually pattern match all the way down! Basically, we want to treat "has a phantom role" and "does not occur" similarly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:12:32 -0000 Subject: [GHC] #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux In-Reply-To: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> References: <047.dd1545e46b04cced27cd3d7886951e4b@haskell.org> Message-ID: <062.5849ced19be80ddd11ccf640743a82cc@haskell.org> #13287: The runtime parses arguments past -- under windows but passes them on as arguments on linux -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T13287 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3147 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:15:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:15:03 -0000 Subject: [GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes In-Reply-To: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> References: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> Message-ID: <065.768a9d709062f30e76810b2e6767ce3c@haskell.org> #13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4028 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The whole `dataCast1`, `dataCast2` business is clearly a hack. It predates kind polymorphism. Could it be cleaned up now we have kind polymorphism? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:16:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:16:33 -0000 Subject: [GHC] #13323: Backpack doesn't work with DuplicateRecordFields In-Reply-To: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> References: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> Message-ID: <060.1854d4999c74f9fd613141e1a6a5d889@haskell.org> #13323: Backpack doesn't work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3175 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"8f8016a5cb006fe14e1058c01a215b90e8435cc8/ghc" 8f8016a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f8016a5cb006fe14e1058c01a215b90e8435cc8" Include OverloadedRecordFields selectors in NameShape. Summary: Fixes #13323. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3175 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:37:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:37:48 -0000 Subject: [GHC] #10731: System.IO.openTempFile is not thread safe on Windows In-Reply-To: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> References: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> Message-ID: <066.ce9639b3060f716529bb2e45634764df@haskell.org> #10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: Phyx- (added) Comment: Phyx-, do you know of a threadsafe way to create and open a temporary file on Windows? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:39:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:39:10 -0000 Subject: [GHC] #13196: Document AMP as a deviation from Haskell 2010 In-Reply-To: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> References: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> Message-ID: <060.65bb809ebf9a762439f09321ce242b42@haskell.org> #13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3185 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:57:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:57:35 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.e33f9b8d377a7227aec13d2967de4df4@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ethercrow Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: | https://phabricator.haskell.org/D3139 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4ad36206285a84bfc3c9f7d41c55bba83bfdffef/ghc" 4ad3620/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ad36206285a84bfc3c9f7d41c55bba83bfdffef" Fix parsing of And chains in BoolFormula Parse `foo, bar, baz` into `And [foo, bar, baz]` instead of `And [foo, And [bar, baz]]`. Fixes #11024. Test Plan: read and think Reviewers: austin, bgamari, mpickering Reviewed By: bgamari, mpickering Subscribers: ezyang, thomie, alanz Differential Revision: https://phabricator.haskell.org/D3139 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 23 23:57:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Feb 2017 23:57:35 -0000 Subject: [GHC] #13310: Cut a new array release In-Reply-To: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> References: <046.78a1c6814a975bd87284888ceb2402ce@haskell.org> Message-ID: <061.d0e6b6e9ab2e3e762fa7c69b2b107b43@haskell.org> #13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8d64395b43cb73d110767cab512a368b3db018de/ghc" 8d64395/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d64395b43cb73d110767cab512a368b3db018de" Correct Windows libdir assumptions. GHC and ghc-pkg make some pretty hard assumptions about where they're running on Windows. They assume that they are always running from `foo/bin/ghc.exe` and that to find the `lib` folder they can drop `bin/ghc.exe` from the base path and append `lib`. This is already false for the testsuite, which when testing thenbindist has one test which puts the binaries in `inplace/test spaces`. For some reason before this was either being skipped or mysteriously passing. But as of `2017.02.11` our luck ran out. the testsuite triggers a failure such as those in #13310 Let's soften the assumption and just check that `../lib` exists instead. 80 chars Test Plan: ./validate Reviewers: austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 00:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 00:06:04 -0000 Subject: [GHC] #13301: GHC base directory assumptions In-Reply-To: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> References: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> Message-ID: <059.87595aef8049023ac34cf25e96639dc2@haskell.org> #13301: GHC base directory assumptions ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3158 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Oops, the commit mentioned the wrong ticket, In [changeset:"8d64395b43cb73d110767cab512a368b3db018de/ghc" 8d64395/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d64395b43cb73d110767cab512a368b3db018de" Correct Windows libdir assumptions. GHC and ghc-pkg make some pretty hard assumptions about where they're running on Windows. They assume that they are always running from `foo/bin/ghc.exe` and that to find the `lib` folder they can drop `bin/ghc.exe` from the base path and append `lib`. This is already false for the testsuite, which when testing thenbindist has one test which puts the binaries in `inplace/test spaces`. For some reason before this was either being skipped or mysteriously passing. But as of `2017.02.11` our luck ran out. the testsuite triggers a failure such as those in #13310 Let's soften the assumption and just check that `../lib` exists instead. 80 chars Test Plan: ./validate Reviewers: austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 00:06:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 00:06:17 -0000 Subject: [GHC] #13301: GHC base directory assumptions In-Reply-To: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> References: <044.9c94fbc58150c22ca9df4fc68e4e53d9@haskell.org> Message-ID: <059.465238b5a955d9bfb00fae8f5eadb291@haskell.org> #13301: GHC base directory assumptions ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3158 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 00:11:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 00:11:06 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn In-Reply-To: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> References: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> Message-ID: <061.7c5e660195c2cbb0929487bdeb60164e@haskell.org> #13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3170 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => bgamari * differential: => Phab:D3170 Comment: I tried to knock this one off while waiting for a build a few days ago, but it's not clear that the patch is quite correct and certainly lacks documentation. I'll need to come back to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 01:50:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 01:50:50 -0000 Subject: [GHC] #13325: Binary distributions produced from cross-compiled stage2 are broken In-Reply-To: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> References: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> Message-ID: <061.0b2109a0e3f6faa96c8312764f75688e@haskell.org> #13325: Binary distributions produced from cross-compiled stage2 are broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8910 | Differential Rev(s): Phab:D3187 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * differential: => Phab:D3187 * milestone: 8.4.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 01:51:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 01:51:55 -0000 Subject: [GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886 In-Reply-To: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> References: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> Message-ID: <061.6480f85d8c549c4995768d745a53a5b8@haskell.org> #10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9058 | Differential Rev(s): Phab:D3188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * differential: => Phab:D3188 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 01:52:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 01:52:01 -0000 Subject: [GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886 In-Reply-To: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> References: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> Message-ID: <061.11c41c162407fdfd8087bca597688dc0@haskell.org> #10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9058 | Differential Rev(s): Phab:D3188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 01:52:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 01:52:58 -0000 Subject: [GHC] Trac email verification for user: irongremlin Message-ID: <20170224015258.6DE253A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: irongremlin Verification Token: UJY8QV1U -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 01:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 01:53:17 -0000 Subject: [GHC] #13325: Binary distributions produced from cross-compiled stage2 are broken In-Reply-To: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> References: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> Message-ID: <061.816232ec7dfe93f9715a14c7c7aaae93@haskell.org> #13325: Binary distributions produced from cross-compiled stage2 are broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8910 | Differential Rev(s): Phab:D3187 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 02:02:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 02:02:02 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.36d55a8ff288c3c42ebc80154de8c1a7@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: deriving-perf 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 RyanGlScott): That proposed `foldMap` implementation has different strictness properties than the current one that `deriving` Foldable uses. That is, this program: {{{#!hs {-# LANGUAGE DeriveFoldable #-} data Phantom a = Z | S (Phantom a) deriving Foldable main :: IO () main = print $ foldMap (const ()) (undefined :: Phantom Int) }}} will throw an exception, whereas this program: {{{#!hs data Phantom a = Z | S (Phantom a) instance Foldable Phantom where foldMap _ _ = mempty main :: IO () main = print $ foldMap (const ()) (undefined :: Phantom Int) }}} will output `()`. I like the intent of this proposal, however. Can the strictness problem be fixed by changing it to `foldMap _ !_ = mempty`/`foldr _ z !_ = z`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 02:16:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 02:16:11 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.a957e732c365011e157b9aa91a4d3523@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: deriving-perf 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 dfeuer): No, you have to pick efficiency or strictness here. The bottom could show up anywhere down the line. I think derived instances should generally go for what someone's likely to write by hand, rather than trying to imitate the lousy results of the default. The default implementation of `null` will diverge on an infinite snoc-list, but that doesn't mean the derived implementation should. I think the same is true here. If the type is phantom, there's no possible reason to go there, so we shouldn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 02:16:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 02:16:44 -0000 Subject: [GHC] #13329: Windows CMD.EXE "Quick Edit Mode" Message-ID: <050.6dd8a7e9c30afcf63396503e6ba3ff0b@haskell.org> #13329: Windows CMD.EXE "Quick Edit Mode" -------------------------------------+------------------------------------- Reporter: irongremlin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: clipboard, | Operating System: Windows quick edit | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Behavior: When a compiled haskell executable launches into a windows 7 'cmd.exe' terminal session, it does not respect the users 'quick edit mode' setting, and launches with the system default setting instead. I have not replicated this issue on other versions of windows. Details: For a description of the feature behavior, see: https://blogs.msdn.microsoft.com/adioltean/2004/12/27/useful-copypaste- trick-in-cmd-exe/ The registry key entry controlling this setting is: HKEY_CURRENT_USER\Console\QuickEdit (1 == on, 0 ==off) Tiny illustrative program: main :: IO () putStrLn "Try to copy this text" >>=(\_ -> getLine) >>= putStrLn Additional notes: The workaround is pretty simple, launch the program from a .bat script - cmd /K myscript.exe Or from inside an existing cmd.exe session, and the problem goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 02:22:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 02:22:05 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.a032e41b204d1fc0f572de1f69e9a135@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: deriving-perf 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 RyanGlScott): I do agree that your proposed definition is probably the better one. I only ask that we point out this change in strictness in the users' guide (and probably the migration guide for whatever GHC release this makes it into) so that users aren't too surprised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 03:26:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 03:26:28 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization Message-ID: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Troubleshooting the T4030 failure in SimonPJ's early-inline branch, Reid and I discovered that the problem showed up when the argument to `forkIO` was obviously bottom. He came up with a tiny test case that fails without Simon's changes: {{{#!hs main = forkIO undefined >> threadDelay 1000000 }}} It looks like the trouble is in the definition of `forkIO`: {{{#!hs forkIO :: IO () -> IO ThreadId forkIO action = IO $ \ s -> case (fork# action_plus s) of (# s1, tid #) -> (# s1, ThreadId tid #) where action_plus = catchException action childHandler }}} This seems to run into the trouble with `catchException` and strictness explained in `GHC.IO`. It would appear that the conservative fix would be to replace `catchException` with `catch`. Personally, I find it a bit surprising that `forkIO` doesn't force its `IO` argument before forking, but changing that behavior could break working code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 03:41:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 03:41:57 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.b5467211821eecb0c91eb744d4d4e912@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.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 rwbarton): To be specific, the expected behavior of the test is for the `undefined` exception to be reported and then for the program to run for a second and then exit. This is the behavior without optimizations, and also the behavior under GHC 7.10 and earlier regardless of optimization level. Basically, the same situation as with `catch` in #11555. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 04:21:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 04:21:08 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.831c3be7d2a70df41b5c43ab581dea8b@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer * differential: => Phab:D3189 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 04:21:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 04:21:20 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.e9fe83de22dabec9dd37cdbbeb909c6b@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 05:27:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 05:27:45 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure Message-ID: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- `nofib` turned up a serious performance bug in the implementation of `insert` in `containers-0.5.10.1`. The function was defined thus: {{{#!hs origInsert :: Ord k => k -> a -> Map k a -> Map k a origInsert = go where go :: Ord k => k -> a -> Map k a -> Map k a go !kx x Tip = singleton kx x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go kx x r EQ | kx `ptrEq` ky && x `ptrEq` y -> t | otherwise -> Bin sz kx x l r {-# INLINABLE origInsert #-} }}} When this specializes to `Int` keys (or any other "unboxable" ones, including tuples), worker/wrapper botches the job: {{{ Rec { -- RHS size: {terms: 102, types: 65, coercions: 0} $w$sgo :: forall a_a7M6. Int# -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 $w$sgo = \ (@ a_a7M6) (ww_s8oI :: Int#) (w_s8oE :: a_a7M6) (w1_s8oF :: Map Int a_a7M6) -> let { kx_X7KQ :: Int kx_X7KQ = I# ww_s8oI } in case w1_s8oF of wild_Xg { [...] origInsertInt_$sgo :: forall a_a7M6. Int -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 origInsertInt_$sgo = \ (@ a_a7M6) (w_s8oD :: Int) (w1_s8oE :: a_a7M6) (w2_s8oF :: Map Int a_a7M6) -> case w_s8oD of _ { I# ww1_s8oI -> $w$sgo ww1_s8oI w1_s8oE w2_s8oF } }}} The wrapper opens the box, throws it away, and passes the contents to the worker, which immediately builds a ''new'' box with exactly the same contents. This prevents the pointer equality tests from succeeding for these types, and it also turns out to cause quite a lot of extra allocation for some types (leading to the severe nofib regression). One could reasonably argue that the code above is a bit complicated, and that GHC could be forgiven for failing to realize that the box should be saved. Unfortunately, a straightforward change that would seem to make this clear does not in fact convince GHC: {{{#!hs myInsert :: Ord k => k -> a -> Map k a -> Map k a myInsert kx0 = go kx0 where go !kx x Tip = singleton kx0 x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go kx x r EQ | kx0 `ptrEq` ky && x `ptrEq` y -> t | otherwise -> Bin sz kx0 x l r {-# INLINABLE myInsert #-} }}} does exactly the same thing. The only ''simple'' way I found to avoid that is to remove the bang patterns, which really ''shouldn't'' work, but does. This, however, is prohibited by the required semantics—we must be strict in the key even if comparison is not. The only fix I've found thus far is truly disgusting, and seems to work at least partly by mistake: {{{#!hs insert :: Ord k => k -> a -> Map k a -> Map k a insert kx0 = go kx0 kx0 where go :: Ord k => k -> k -> a -> Map k a -> Map k a go orig !kx x Tip = singleton (lazy orig) x go orig !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go orig kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go orig kx x r EQ | x `ptrEq` y && (lazy orig `seq` (orig `ptrEq` ky)) -> t | otherwise -> Bin sz (lazy orig) x l r {-# INLINABLE insert #-} }}} We would also like to be able to experiment with an implementation that uses CPS (recursive join points today!) rather than pointer equality tests for the internal nodes, leaving pointer equality to the leaves. But I have not found any way whatsoever to avoid this W/W problem in that version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 05:31:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 05:31:16 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.b88aef3b26ab198884c0025cab93fc7e@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > `nofib` turned up a serious performance bug in the implementation of > `insert` in `containers-0.5.10.1`. The function was defined thus: > > {{{#!hs > origInsert :: Ord k => k -> a -> Map k a -> Map k a > origInsert = go > where > go :: Ord k => k -> a -> Map k a -> Map k a > go !kx x Tip = singleton kx x > go !kx x t@(Bin sz ky y l r) = > case compare kx ky of > LT | l' `ptrEq` l -> t > | otherwise -> balanceL ky y l' r > where !l' = go kx x l > GT | r' `ptrEq` r -> t > | otherwise -> balanceR ky y l r' > where !r' = go kx x r > EQ | kx `ptrEq` ky && x `ptrEq` y -> t > | otherwise -> Bin sz kx x l r > > {-# INLINABLE origInsert #-} > }}} > > When this specializes to `Int` keys (or any other "unboxable" ones, > including tuples), worker/wrapper botches the job: > > {{{ > Rec { > -- RHS size: {terms: 102, types: 65, coercions: 0} > $w$sgo > :: forall a_a7M6. > Int# -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 > $w$sgo = > \ (@ a_a7M6) > (ww_s8oI :: Int#) > (w_s8oE :: a_a7M6) > (w1_s8oF :: Map Int a_a7M6) -> > let { > kx_X7KQ :: Int > kx_X7KQ = I# ww_s8oI } in > case w1_s8oF of wild_Xg { > > [...] > > origInsertInt_$sgo > :: forall a_a7M6. Int -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 > origInsertInt_$sgo = > \ (@ a_a7M6) > (w_s8oD :: Int) > (w1_s8oE :: a_a7M6) > (w2_s8oF :: Map Int a_a7M6) -> > case w_s8oD of _ { I# ww1_s8oI -> $w$sgo ww1_s8oI w1_s8oE w2_s8oF } > }}} > > The wrapper opens the box, throws it away, and passes the contents to the > worker, which immediately builds a ''new'' box with exactly the same > contents. This prevents the pointer equality tests from succeeding for > these types, and it also turns out to cause quite a lot of extra > allocation for some types (leading to the severe nofib regression). > > One could reasonably argue that the code above is a bit complicated, and > that GHC could be forgiven for failing to realize that the box should be > saved. Unfortunately, a straightforward change that would seem to make > this clear does not in fact convince GHC: > > {{{#!hs > myInsert :: Ord k => k -> a -> Map k a -> Map k a > myInsert kx0 = go kx0 > where > go !kx x Tip = singleton kx0 x > go !kx x t@(Bin sz ky y l r) = > case compare kx ky of > LT | l' `ptrEq` l -> t > | otherwise -> balanceL ky y l' r > where !l' = go kx x l > GT | r' `ptrEq` r -> t > | otherwise -> balanceR ky y l r' > where !r' = go kx x r > EQ | kx0 `ptrEq` ky && x `ptrEq` y -> t > | otherwise -> Bin sz kx0 x l r > > {-# INLINABLE myInsert #-} > }}} > > does exactly the same thing. The only ''simple'' way I found to avoid > that is to remove the bang patterns, which really ''shouldn't'' work, but > does. This, however, is prohibited by the required semantics—we > must be strict in the key even if comparison is not. The only fix I've > found thus far is truly disgusting, and seems to work at least partly by > mistake: > > {{{#!hs > insert :: Ord k => k -> a -> Map k a -> Map k a > insert kx0 = go kx0 kx0 > where > go :: Ord k => k -> k -> a -> Map k a -> Map k a > go orig !kx x Tip = singleton (lazy orig) x > go orig !kx x t@(Bin sz ky y l r) = > case compare kx ky of > LT | l' `ptrEq` l -> t > | otherwise -> balanceL ky y l' r > where !l' = go orig kx x l > GT | r' `ptrEq` r -> t > | otherwise -> balanceR ky y l r' > where !r' = go orig kx x r > EQ | x `ptrEq` y && (lazy orig `seq` (orig `ptrEq` ky)) -> t > | otherwise -> Bin sz (lazy orig) x l r > > {-# INLINABLE insert #-} > }}} > > We would also like to be able to experiment with an implementation that > uses CPS (recursive join points today!) rather than pointer equality > tests for the internal nodes, leaving pointer equality to the leaves. But > I have not found any way whatsoever to avoid this W/W problem in that > version. New description: `nofib` turned up a serious performance bug in the implementation of `insert` in `containers-0.5.10.1`. The function was defined thus: {{{#!hs origInsert :: Ord k => k -> a -> Map k a -> Map k a origInsert = go where go :: Ord k => k -> a -> Map k a -> Map k a go !kx x Tip = singleton kx x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go kx x r EQ | kx `ptrEq` ky && x `ptrEq` y -> t | otherwise -> Bin sz kx x l r {-# INLINABLE origInsert #-} }}} When this specializes to `Int` keys (or any other "unboxable" ones, including tuples), worker/wrapper botches the job: {{{ Rec { -- RHS size: {terms: 102, types: 65, coercions: 0} $w$sgo :: forall a_a7M6. Int# -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 $w$sgo = \ (@ a_a7M6) (ww_s8oI :: Int#) (w_s8oE :: a_a7M6) (w1_s8oF :: Map Int a_a7M6) -> let { kx_X7KQ :: Int kx_X7KQ = I# ww_s8oI } in case w1_s8oF of wild_Xg { [...] origInsertInt_$sgo :: forall a_a7M6. Int -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 origInsertInt_$sgo = \ (@ a_a7M6) (w_s8oD :: Int) (w1_s8oE :: a_a7M6) (w2_s8oF :: Map Int a_a7M6) -> case w_s8oD of _ { I# ww1_s8oI -> $w$sgo ww1_s8oI w1_s8oE w2_s8oF } }}} The wrapper opens the box, throws it away, and passes the contents to the worker, which immediately builds a ''new'' box with exactly the same contents. This prevents the pointer equality tests from succeeding for these types, and it also turns out to cause quite a lot of extra allocation for some types (leading to the severe nofib regression). One could reasonably argue that the code above is a bit complicated, and that GHC could be forgiven for failing to realize that the box should be saved. Unfortunately, a straightforward change that would seem to make this clear does not in fact convince GHC: {{{#!hs myInsert :: Ord k => k -> a -> Map k a -> Map k a myInsert kx0 = go kx0 where go !kx x Tip = singleton kx0 x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go kx x r EQ | kx0 `ptrEq` ky && x `ptrEq` y -> t | otherwise -> Bin sz kx0 x l r {-# INLINABLE myInsert #-} }}} does exactly the same thing. The only ''simple'' way I found to avoid that is to remove the bang patterns, which really ''shouldn't'' work, but does. This, however, is prohibited by the desired semantics—I believe we want to be strict in the key even if comparison is not. In any case, that really shouldn't be causing trouble and it is. The only fix I've found thus far is truly disgusting, and seems to work at least partly by mistake: {{{#!hs insert :: Ord k => k -> a -> Map k a -> Map k a insert kx0 = go kx0 kx0 where go :: Ord k => k -> k -> a -> Map k a -> Map k a go orig !kx x Tip = singleton (lazy orig) x go orig !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go orig kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go orig kx x r EQ | x `ptrEq` y && (lazy orig `seq` (orig `ptrEq` ky)) -> t | otherwise -> Bin sz (lazy orig) x l r {-# INLINABLE insert #-} }}} We would also like to be able to experiment with an implementation that uses CPS (recursive join points today!) rather than pointer equality tests for the internal nodes, leaving pointer equality to the leaves. But I have not found any way whatsoever to avoid this W/W problem in that version. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 05:37:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 05:37:12 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier Message-ID: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> #13332: Report unrecognized pragmas earlier -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, I have a typo in the `UndecidableInstances` pragma (`LANGUAGE` is misspelled), however, GHC ''only'' reports that `UndecidableInstances` is required. This is very confusing, since it appears that I have enabled that pragma. {{{ {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANUGAGE UndecidableInstances #-} instance (Num [a]) => Num a }}} Only when I comment out the instance does GHC report that there is an unrecognized pragma, at which point it became obvious that there was a typo. It would be very helpful if GHC reported the warning about the unrecognized pragma before or at the same time as the error about needing `UndecidableInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 07:17:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 07:17:22 -0000 Subject: [GHC] #10731: System.IO.openTempFile is not thread safe on Windows In-Reply-To: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> References: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> Message-ID: <066.65735b87b5a7f4dde0eb69b7aaea73d3@haskell.org> #10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): [https://msdn.microsoft.com/en- us/library/windows/desktop/aa364991(v=vs.85).aspx GetTempFileName] with `uUnique` 0 should be thread safe. The call will do most of the steps described in comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 09:05:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 09:05:00 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.0921f242b50e3f5cc35b6b1d6807b912@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch 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:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a6e13d502ef46de854ec1babcd764ccce68c95e3/ghc" a6e13d50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6e13d502ef46de854ec1babcd764ccce68c95e3" Make exprIsConApp_maybe work better for literals strings There are two things here * Use exprIsLiteral_maybe to "look through" a variable bound to a literal string. * Add CONLIKE to the NOINLINE pragma for unpackCString# and unpackCStringUtf8# See Trac #13317, Trac #10844, and Note [exprIsConApp_maybe on literal strings] in CoreSubst I did a nofib run and got essentially zero change except for one 2.2% improvement in allocation for 'pretty'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 09:05:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 09:05:01 -0000 Subject: [GHC] #13317: exprIsConApp_maybe should deal better with strings In-Reply-To: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> References: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> Message-ID: <061.8c9ce305357c7b283aa99d147376e524@haskell.org> #13317: exprIsConApp_maybe should deal better with strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a6e13d502ef46de854ec1babcd764ccce68c95e3/ghc" a6e13d50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6e13d502ef46de854ec1babcd764ccce68c95e3" Make exprIsConApp_maybe work better for literals strings There are two things here * Use exprIsLiteral_maybe to "look through" a variable bound to a literal string. * Add CONLIKE to the NOINLINE pragma for unpackCString# and unpackCStringUtf8# See Trac #13317, Trac #10844, and Note [exprIsConApp_maybe on literal strings] in CoreSubst I did a nofib run and got essentially zero change except for one 2.2% improvement in allocation for 'pretty'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 09:18:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 09:18:55 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.ffd0fb0221c78258969649b30da6eb03@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Strange. The definition of `catch` is just {{{ catch act = catchException (lazy act) }}} for reasons extensively documented in #11555. So `catchException` has different, less desirable, and undocumented behaviour. Should move the `lazy` into `catchException`? So then `catch = catchException`. Do we actually want the distinction? Incidentally, the use of 'lazy' in `catch` is entirely un-documented. No `Note` no nothing. While fixing this ticket it would be good to fix that too. At every least a reference to #11555! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 09:27:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 09:27:29 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.87adeb26e5e79c6b47de02a9996a640e@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 simonpj): Can you make a repro case? What is this `ptrEq` thing? It looks very smelly to me. Surely at least it should be called `unsafePtrEq`. What does it do? Reboxing in worker/wrapper is very difficult to avoid. It was described in our original strictness analysis paper, and also in the paper about constructor specialisation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 09:29:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 09:29:09 -0000 Subject: [GHC] #13317: exprIsConApp_maybe should deal better with strings In-Reply-To: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> References: <046.e8a25721bfd010ed64bf03d56f5047aa@haskell.org> Message-ID: <061.e739d659358e75113a38cf6c37939245@haskell.org> #13317: exprIsConApp_maybe should deal better with strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13317 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T13317 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 10:36:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 10:36:14 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.5e82b6d6a281012ec92f8c089ea74016@haskell.org> #13332: Report unrecognized pragmas earlier -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 10:54:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 10:54:34 -0000 Subject: [GHC] Trac email verification for user: _recursion Message-ID: <20170224105434.AA8403A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: _recursion Verification Token: Zf4Wsroc -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 12:16:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 12:16:47 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.c736c623d27bf734a2e428b3f1a0cc34@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => closed * resolution: => worksforme Comment: Edsko, please reopen if you still cannot make it work with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 16:17:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 16:17:53 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.0901db64da073b8d35415702a0aa44fa@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): `ptrEq` is indeed a thin wrapper around `reallyUnsafePtrEquality#`: {{{#!hs ptrEq :: a -> a -> Bool ptrEq x y = tagToEnum# (reallyUnsafePtrEquality# x y) }}} If it's really hard to work this out automatically, I wonder if it could be made a little easier with a pragma. I'd be satisfied if I could write something like {{{#!hs go :: Ord k => {-# NOUNPACK #-} k -> k -> a -> Map k a -> Map k a }}} to indicate that GHC should not unbox the first argument. Would that make it easier to avoid the problem? I'd hate to leave something as fragile- looking as my workaround hack in `containers` forever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 16:25:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 16:25:17 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.c6703b590d79b692b62a5020a0f6d885@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 simonpj): I'd still like to check a repro case. Without it I'm guessing wildly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 16:34:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 16:34:29 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.ab65899ba3bad5eac6429e0ccd4246b2@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch 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:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Phab:D1259 does floating in the desugarer. We should document carefully here the reason that the `FloatOut` pass doesn't nail this; I keep forgetting. It's because functions with an INLINE pragma are supposed to inline precisely the RHS, so FloatOut doesn't float anything out of a stable unfolding. So we are instead doing it in the desugarer, the same place that the stable unfoldings are built in the first place. But we should pursue your idea from comment:11: ''GHC should not inline terms that the programmer did not write''. In particular, perhaps when you write an incomplete pattern match, the catch-all error message could be plonked (by the desugarer) at top level? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 16:55:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 16:55:08 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.fdba0b660c5a7fd7508dcb2616181f3a@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Wait - what ''is'' the semantics implemented in HEAD? Is it the one we want? Why does it make a difference whether `g` is inlined or not? What do you mean by your last sentence: > I couldn't be sure, but I'm more inclined to think that the current (hopefully correct) implementation is more of an accident than a designed behavior. Do each one of the examples I write at the top of [comment:7 this comment] pass/don't pass as expected in GHC HEAD? If so, which commit changed that in HEAD and where these changes intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 16:57:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 16:57:02 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.97217805314671a56e3554e71f13efa7@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): * Attachment "Repro13331.hs" added. Repro case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 17:09:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 17:09:02 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.91dab2959d19a3697f799cc6f65f6627@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): Actually, I just discovered that we don't even need pointer equality to reproduce! {{{#!hs naiveInsert1 :: Ord k => k -> a -> Map k a -> Map k a naiveInsert1 kx0 = go kx0 where --go :: Ord k => k -> a -> Map k a -> Map k a go !kx x Tip = singleton kx0 x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT -> balanceL ky y l' r where !l' = go kx x l GT -> balanceR ky y l r' where !r' = go kx x r EQ -> Bin sz kx0 x l r {-# INLINABLE naiveInsert1 #-} }}} and {{{#!hs naiveInsert2 :: Ord k => k -> a -> Map k a -> Map k a naiveInsert2 = go where go :: Ord k => k -> a -> Map k a -> Map k a go !kx x Tip = singleton kx x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT -> balanceL ky y l' r where !l' = go kx x l GT -> balanceR ky y l r' where !r' = go kx x r EQ -> Bin sz kx x l r {-# INLINABLE naiveInsert2 #-} }}} both demonstrate the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 17:16:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 17:16:11 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.245f5d59231f14b9a7b30dcb2341324b@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): * Attachment "Minimal13331.hs" added. A smaller reproduction -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 18:43:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 18:43:55 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.04b1026eb9c97c5899b768e7481b1283@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): > Why does it make a difference whether g is inlined or not? The crucial difference between type-checking a local `g` and type-checking the body of the static form, is that `g` has the context of the enclosing function available, whereas the body of the static form does not. Therefore, inlining has the effect of removing the constraints of the enclosing function, and in return, it allows types to be non-closed. > Do each one of the examples I write at the top of this comment pass/don't pass as expected in GHC HEAD? I only see one example. And yes, it does pass. > If so, which commit changed that in HEAD and where these changes intentional? The commit which allows closed variables in static forms: http://git.haskell.org/ghc.git/commit/36d29f7ce332a2b1fbc36de831b0eef7a6405555 The relevant bit of the commit message reads {{{ The renamer does not check anymore if free variables appearing in the static form are top-level. Instead, the typechecker looks at the tct_closed flag to decide if the free variables are closed. }}} > and where these changes intentional? I don't remember being aware of this aspect before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 18:46:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 18:46:04 -0000 Subject: [GHC] #13196: Document AMP as a deviation from Haskell 2010 In-Reply-To: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> References: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> Message-ID: <060.25aecd349a58af8850e93d76f2c55127@haskell.org> #13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3185 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"93ffcb028630df97bda82f16a103e3c8ffdaba35/ghc" 93ffcb02/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="93ffcb028630df97bda82f16a103e3c8ffdaba35" Document AMP as a Report deviation `Applicative` as a superclass of `Monad` is non-standard. Fixes #13196. [skip ci] Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3185 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 18:47:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 18:47:59 -0000 Subject: [GHC] #13196: Document AMP as a deviation from Haskell 2010 In-Reply-To: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> References: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> Message-ID: <060.c4033ffb8c0b53a3788f5346b40943a0@haskell.org> #13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 19:30:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 19:30:22 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD Message-ID: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- I recently wrote some code while exploring a fix for #13327 that heavily uses poly-kinded `Typeable`. This compiles without issue on GHC 8.0.1 and 8.0.2: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module DataCast where import Data.Data import GHC.Exts (Constraint) data T (phantom :: k) = T data D (p :: k -> Constraint) (x :: j) where D :: forall (p :: k -> Constraint) (x :: k). p x => D p x class Possibly p x where possibly :: proxy1 p -> proxy2 x -> Maybe (D p x) dataCast1T :: forall k c t (phantom :: k). (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) dataCast1T f = case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f }}} But on GHC HEAD, it barfs this error: {{{ Bug.hs:28:29: error: • Could not deduce (Typeable T) arising from a use of ‘gcast1’ GHC can't yet do polykinded Typeable (T :: * -> *) from the context: (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) bound by the type signature for: dataCast1T :: (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) at Bug.hs:(22,1)-(25,35) or from: (k ~ *, (phantom :: k) ~~ (x :: *), Data x) bound by a pattern with constructor: D :: forall k (p :: k -> Constraint) (x :: k). p x => D p x, in a case alternative at Bug.hs:28:23 • In the expression: gcast1 f In a case alternative: Just D -> gcast1 f In the expression: case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f | 28 | Just D -> gcast1 f | ^^^^^^^^ }}} That error message itself is hilariously strange, since GHC certainly has the power to do polykinded `Typeable` nowadays. Marking as high priority since this is a regression—feel free to lower the priority if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 19:37:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 19:37:45 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.8d6a004a6d2e8c128345f1aa58c0a8b3@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > I recently wrote some code while exploring a fix for #13327 that heavily > uses poly-kinded `Typeable`. This compiles without issue on GHC 8.0.1 and > 8.0.2: > > {{{#!hs > {-# LANGUAGE ConstraintKinds #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeInType #-} > {-# LANGUAGE TypeOperators #-} > module DataCast where > > import Data.Data > import GHC.Exts (Constraint) > > data T (phantom :: k) = T > > data D (p :: k -> Constraint) (x :: j) where > D :: forall (p :: k -> Constraint) (x :: k). p x => D p x > > class Possibly p x where > possibly :: proxy1 p -> proxy2 x -> Maybe (D p x) > > dataCast1T :: forall k c t (phantom :: k). > (Typeable k, Typeable t, Typeable phantom, Possibly Data > phantom) > => (forall d. Data d => c (t d)) > -> Maybe (c (T phantom)) > dataCast1T f = case possibly (Proxy :: Proxy Data) (Proxy :: Proxy > phantom) of > Nothing -> Nothing > Just D -> gcast1 f > }}} > > But on GHC HEAD, it barfs this error: > > {{{ > Bug.hs:28:29: error: > • Could not deduce (Typeable T) arising from a use of ‘gcast1’ > GHC can't yet do polykinded Typeable (T :: * -> *) > from the context: (Typeable k, Typeable t, Typeable phantom, > Possibly Data phantom) > bound by the type signature for: > dataCast1T :: (Typeable k, Typeable t, Typeable > phantom, > Possibly Data phantom) => > (forall d. Data d => c (t d)) -> Maybe > (c (T phantom)) > at Bug.hs:(22,1)-(25,35) > or from: (k ~ *, (phantom :: k) ~~ (x :: *), Data x) > bound by a pattern with constructor: > D :: forall k (p :: k -> Constraint) (x :: k). p x => > D p x, > in a case alternative > at Bug.hs:28:23 > • In the expression: gcast1 f > In a case alternative: Just D -> gcast1 f > In the expression: > case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of > Nothing -> Nothing > Just D -> gcast1 f > | > 28 | Just D -> gcast1 f > | ^^^^^^^^ > }}} > > That error message itself is hilariously strange, since GHC certainly has > the power to do polykinded `Typeable` nowadays. > > Marking as high priority since this is a regression—feel free to lower > the priority if you disagree. New description: I recently wrote some code while exploring a fix for #13327 that heavily uses poly-kinded `Typeable`. This compiles without issue on GHC 8.0.1 and 8.0.2: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module DataCast where import Data.Data import GHC.Exts (Constraint) data T (phantom :: k) = T data D (p :: k -> Constraint) (x :: j) where D :: forall (p :: k -> Constraint) (x :: k). p x => D p x class Possibly p x where possibly :: proxy1 p -> proxy2 x -> Maybe (D p x) dataCast1T :: forall k c t (phantom :: k). (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) dataCast1T f = case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f }}} But on GHC HEAD, it barfs this error: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.1.20170223: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling DataCast ( Bug.hs, interpreted ) Bug.hs:28:29: error: • Could not deduce (Typeable T) arising from a use of ‘gcast1’ GHC can't yet do polykinded Typeable (T :: * -> *) from the context: (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) bound by the type signature for: dataCast1T :: (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) at Bug.hs:(22,1)-(25,35) or from: (k ~ *, (phantom :: k) ~~ (x :: *), Data x) bound by a pattern with constructor: D :: forall k (p :: k -> Constraint) (x :: k). p x => D p x, in a case alternative at Bug.hs:28:23 • In the expression: gcast1 f In a case alternative: Just D -> gcast1 f In the expression: case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f | 28 | Just D -> gcast1 f | ^^^^^^^^ }}} That error message itself is hilariously strange, since GHC certainly has the power to do polykinded `Typeable` nowadays. Marking as high priority since this is a regression—feel free to lower the priority if you disagree. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 19:40:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 19:40:42 -0000 Subject: [GHC] #13315: Compile broken on new MSYS2 In-Reply-To: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> References: <044.15a1c8f23035e834dd51d3af53f3271d@haskell.org> Message-ID: <059.404286e44ab0022c4e1c6ff5efc2e557@haskell.org> #13315: Compile broken on new MSYS2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => closed * resolution: => fixed Comment: upstream has reverted the change made by cygwin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 19:44:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 19:44:25 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.3d1f15575b6c54f68dc08510522fe257@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: upstream Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2917 Wiki Page: | Phab:/D2942 -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => ⊥ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 19:44:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 19:44:53 -0000 Subject: [GHC] #13305: static: check for identifiers should only consider term level variables In-Reply-To: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> References: <044.37d96c953726d1ed55f1936dae173c6c@haskell.org> Message-ID: <059.4352bcbd2fc0c2096b5f5f8f20d7e471@haskell.org> #13305: static: check for identifiers should only consider term level variables -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Tried all of these and they were accepted by ghc: {{{ f0 :: StaticPtr (Int -> Int) f0 = static id f1 :: Typeable a => StaticPtr (a -> a) f1 = static id f2 :: Typeable a => Dict (Num a) -> StaticPtr (a -> a) f2 Dict = static id f3 :: Typeable a => StaticPtr (Dict (Num a) -> a -> a) f3 = static (\Dict -> (+1)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 20:41:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 20:41:10 -0000 Subject: [GHC] #13316: Bad inlining cascade leads to slow optimisation In-Reply-To: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> References: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> Message-ID: <061.5f4f1ac6cff3fd476dc808c2b04983a2@haskell.org> #13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ethercrow): * cc: ethercrow (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 21:18:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 21:18:04 -0000 Subject: [GHC] #13334: Constant folding for repeated integer operation of unknown value Message-ID: <046.85ca62ef7997cf4fd4ebfc291337a4ae@haskell.org> #13334: Constant folding for repeated integer operation of unknown value -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- While looking at Phab:D3197 I noticed that currently there is nothing to turn an expression of the form `n+n+...+n` into `n*m`. It seems like some rules like, {{{ forall x. x +# x = 2*x forall n x. n*x + x = (n+1) * x forall n x. x + n*x = (n+1) * x }}} Might fix this. Of course, it's quite possible that a string of additions **is** sometimes faster than a multiplication, but it seems to me that we should (for integer types) perform the rewrite to multiplication and then teach the code generator to lower to addition if it deems it advantageous. Naturally, this also applies to other integer operators as well. Regardless, I doubt that this is hurting anyone too badly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 21:54:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 21:54:21 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.c075177e86d6c69cd210db347727acb7@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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 RyanGlScott): I've observed something even stranger about this program. Let's tweak it slightly and add a couple more things (note that the definition of `dataCast1T` is unchanged): {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module DataCast where import Data.Data import GHC.Exts (Constraint) data T (phantom :: k) = T data D (p :: k -> Constraint) (x :: j) where D :: forall (p :: k -> Constraint) (x :: k). p x => D p x class Possibly p x where possibly :: proxy1 p -> proxy2 x -> Maybe (D p x) instance Possibly Data () where possibly _ _ = Just D dataCast1T :: forall k c t (phantom :: k). (Typeable k, Typeable t, Typeable phantom, Possibly Data phantom) => (forall d. Data d => c (t d)) -> Maybe (c (T phantom)) dataCast1T f = case possibly (Proxy :: Proxy Data) (Proxy :: Proxy phantom) of Nothing -> Nothing Just D -> gcast1 f newtype Q q x = Q { unQ :: x -> q } ext1Q :: (Typeable k, Typeable t, Typeable (phantom :: k), Possibly Data phantom) => (T phantom -> q) -> (forall e. Data e => t e -> q) -> T phantom -> q ext1Q def ext arg = case dataCast1T (Q ext) of Just (Q ext') -> ext' arg Nothing -> def arg }}} With GHC HEAD, this gives the same error as the original program. But if you add this one definition to this file: {{{#!hs test1 :: Char test1 = (const 'p') `ext1Q` (\T -> 'q') $ (T :: T ()) }}} Then it typechecks without issue on GHC HEAD! This is pretty bizarre, considering that the error was originally reported in `dataCast1T`, and we managed to make the error go away without making a single change to `dataCast1T`. FWIW, this program also compiles without issue on GHC 8.0.2 (with and without `test1`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 22:32:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 22:32:12 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.8f1930661d6a16fd6c7112231758fbf1@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: typeable 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 bgamari): * keywords: => typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 22:32:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 22:32:18 -0000 Subject: [GHC] #13329: Windows CMD.EXE "Quick Edit Mode" In-Reply-To: <050.6dd8a7e9c30afcf63396503e6ba3ff0b@haskell.org> References: <050.6dd8a7e9c30afcf63396503e6ba3ff0b@haskell.org> Message-ID: <065.4a0b8ba53e166e7df9419785e75b91f1@haskell.org> #13329: Windows CMD.EXE "Quick Edit Mode" -------------------------------------+------------------------------------- Reporter: irongremlin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: clipboard, | quick edit Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Behavior: > > When a compiled haskell executable launches into a windows 7 'cmd.exe' > terminal session, it does not respect the users 'quick edit mode' > setting, and launches with the system default setting instead. > > I have not replicated this issue on other versions of windows. > > Details: > For a description of the feature behavior, see: > https://blogs.msdn.microsoft.com/adioltean/2004/12/27/useful-copypaste- > trick-in-cmd-exe/ > > The registry key entry controlling this setting is: > HKEY_CURRENT_USER\Console\QuickEdit (1 == on, 0 ==off) > > Tiny illustrative program: > > main :: IO () > putStrLn "Try to copy this text" >>=(\_ -> getLine) >>= putStrLn > > Additional notes: > > The workaround is pretty simple, launch the program from a .bat script - > > cmd /K myscript.exe > > Or from inside an existing cmd.exe session, and the problem goes away. New description: Behavior: When a compiled haskell executable launches into a windows 7 `cmd.exe` terminal session, it does not respect the users `quick edit mode` setting, and launches with the system default setting instead. I have not replicated this issue on other versions of windows. Details: For a description of the feature behavior, see: https://blogs.msdn.microsoft.com/adioltean/2004/12/27/useful-copypaste- trick-in-cmd-exe/ The registry key entry controlling this setting is: `HKEY_CURRENT_USER\Console\QuickEdit` (1 == on, 0 ==off) Tiny illustrative program: {{{ main :: IO () main = putStrLn "Try to copy this text" >>=(\_ -> getLine) >>= putStrLn }}} Additional notes: The workaround is pretty simple, launch the program from a `.bat` script - {{{ cmd /K myscript.exe }}} Or from inside an existing `cmd.exe` session, and the problem goes away. -- Comment (by Phyx-): Thanks for the report, I'll look into this soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 22:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 22:32:49 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it reduces away In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.401446bcfae92a26798d21a60d8211aa@haskell.org> #13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: lowest => low Comment: Actually, I realized that something stronger would be OK here: it's OK for a type family synonym to occur in an instance, even if it doesn't reduce away, AS LONG AS the expression has no free variables. This is pretty useless for normal programmers but actually it is pretty useful in Backpack. Consider: {{{ -- there's some type family F a :: * -> * data T instance Monad (F T) where ... }}} This is something that I'd really quite like to write in a signature, because what I am saying is that there is some existing type family F, and whatever it is the abstract type you picked, F T better reduce to a monad. Yes I could replace the type family with another abstract type for the monad, but if I want Backpack and the type family to coexist, I get better backwards compatibility by reusing the type family. The analogy is how we handle type families in constraints: {{{ f :: Monad (F a) => .... }}} This is OK because `a` is a skolem variable, so we aren't ever going to instantiate it to some variable while we're typechecking the body of f. What would be wrong, and is impossible to write in Haskell's type language today, is `f :: (forall a. Monad (F a)) => ...`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 22:53:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 22:53:01 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.70206609dedbba94f6defc7e0059641f@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3174 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"9d17028fbcecb53480598c4fcc7bd9e71b2ac7cf/ghc" 9d17028f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d17028fbcecb53480598c4fcc7bd9e71b2ac7cf" Record full FieldLabel in ifConFields. Summary: The previous implementation tried to be "efficient" by storing field names once in IfaceConDecls, and only just enough information for us to reconstruct the FieldLabel. But this came at a bit of code complexity cost. This patch undos the optimization, instead storing a full FieldLabel at each data constructor. Consequently, this fixes bugs #12699 and #13250. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: adamgundry, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3174 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 22:53:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 22:53:01 -0000 Subject: [GHC] #13250: Backpack: matching newtype selectors doesn't work In-Reply-To: <045.0e7a960652fd03d6405838b3d76bce63@haskell.org> References: <045.0e7a960652fd03d6405838b3d76bce63@haskell.org> Message-ID: <060.43d92abf3a0a4b35557bab3274ebe3bc@haskell.org> #13250: Backpack: matching newtype selectors doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"9d17028fbcecb53480598c4fcc7bd9e71b2ac7cf/ghc" 9d17028f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d17028fbcecb53480598c4fcc7bd9e71b2ac7cf" Record full FieldLabel in ifConFields. Summary: The previous implementation tried to be "efficient" by storing field names once in IfaceConDecls, and only just enough information for us to reconstruct the FieldLabel. But this came at a bit of code complexity cost. This patch undos the optimization, instead storing a full FieldLabel at each data constructor. Consequently, this fixes bugs #12699 and #13250. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: adamgundry, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3174 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 23:03:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 23:03:45 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.e69910c0c5ae05a523afbf459db561a5@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 simonpj]: > Strange. The definition of `catch` is just > {{{ > catch act = catchException (lazy act) > }}} > for reasons extensively documented in #11555. So `catchException` has different, less desirable, and undocumented behaviour. > > Should move the `lazy` into `catchException`? So then `catch = catchException`. Do we actually want the distinction? > > Incidentally, the use of 'lazy' in `catch` is entirely un-documented. No `Note` no nothing. While fixing this ticket it would be good to fix that too. At every least a reference to #11555! Yes, I can document the `lazy` in `catch`. The distinction probably ''does'' make sense, although it was documented quite incorrectly. The situation here is a bit tricky: we are trying to deal with the fact that `catch#` evaluates its argument ''eagerly'', but is nevertheless ''non- strict'' in that argument. The current approach is to lie a little and tell the demand analyzer that `catch#` is strict in its argument. `catchException` inherits this lie. To avoid getting caught in a lie, and to avoid fragile case-specific reasoning, the invariant we must maintain is that `catchException` is never called with an undefined argument. When this invariant holds, the analysis should end up being pretty much correct: 1. It's safe to evaluate the argument and/or its dependencies early, because it will not fail. 2. After the `catchException` runs, its argument will be in WHNF. An alternative approach that smells more honest to me might be to reveal the fact that `catch#` is actually lazy in its argument, remove the `lazy` call from `catch`, and make `catchException` actually force its argument. I don't know if that would have any negative performance or other consequences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 23:16:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 23:16:42 -0000 Subject: [GHC] #11006: Warning: Glomming in Main In-Reply-To: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> References: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> Message-ID: <060.6d2873bbba9d4cd055fc708940c1767b@haskell.org> #11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: invalid | 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 mpickering): * status: new => closed * resolution: => invalid Comment: Please reopen if this is still an issue but I can't see how to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 23:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 23:18:17 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.953aad33cb71d95a5216efd26d7323ac@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13262 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * blockedby: => 13262 Comment: This ticket is blocked on #13262. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 23:20:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 23:20:17 -0000 Subject: [GHC] #13335: Non-abstract types also have skolem nature Message-ID: <045.1cd550b891f74e462b3401513f54bedb@haskell.org> #13335: Non-abstract types also have skolem nature -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | 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 #12680, we determined that abstract types from signatures need to be treated like skolem variables. But it turns out other types from signatures also need to be treated like skolem variables too: {{{ {-# LANGUAGE GADTs #-} unit p where signature M1 where data A = MkA signature M2 where data A = MkA module A where import qualified M1 import qualified M2 f :: M1.A ~ M2.A => a -> b f x = x }}} This is bad because these As could be the same thing in the end. I think the real, final fix, is to not test for "skolem abstractness" (as we do now), but just look and see if the Name for the TyCon is a name hole or not. Then we can eliminate skolem abstract completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 23:29:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 23:29:39 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.85bff641f6fd7de0ab943418d4857616@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:5 dfeuer]: > To avoid getting caught in a lie, and to avoid fragile case-specific reasoning, the invariant we must maintain is that `catchException` is never called with an undefined argument. When this invariant holds, the analysis should end up being pretty much correct: > > 1. It's safe to evaluate the argument and/or its dependencies early, because it will not fail. > > 2. After the `catchException` runs, its argument will be in WHNF. Agreed, though we might also document what could happen if the argument actually is bottom (namely `catch#` will not catch the exception). > An alternative approach that smells more honest to me might be to reveal the fact that `catch#` is actually lazy in its argument, remove the `lazy` call from `catch`, and make `catchException` actually force its argument. I don't know if that would have any negative performance or other consequences. Interesting idea. It would mean an extra `seq` in the original program, but I think GHC would normally be able to eliminate the `seq` easily. If this works it might lead to a simpler design; but not urgent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 24 23:33:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Feb 2017 23:33:32 -0000 Subject: [GHC] #13336: Improve or remove the glomming warning Message-ID: <049.d59b9b11467efecc0744316f457902ac@haskell.org> #13336: Improve or remove the glomming warning -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- In the GHC build log there's lots of warnings about "glomming" but they are not actionable. The first problem is understanding what glomming is, that much is explained in the `Note [Glomming]`, In my own words, in the occurence analyser there are situations where there are out of scope top-level bindings. This usually happens when a rule is fired which drops in a new binding which does not appear anywhere else other than in rules. GHC dutifully warns us about this event but I can't work out why it this is necessary. What is bad about glomming? It seems like normal and expected behaviour for this to happen, further, there isn't really anything you can do about it. If it is a worthwhile warning to investigate, then the debugging output should be improved as the output is currently a list of uniques with occurence information which is difficult to map to source files. It would be much more useful to display the user-level names of the glommed identifiers. For a real world example look in `Data.Maybe`, compiling this module with a debugging compiler will emit a warning about glomming because of `mapMaybeFB` which appears on the RHS of rules but not anywhere else in a module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 00:06:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 00:06:30 -0000 Subject: [GHC] #12223: Get rid of extra_files.py In-Reply-To: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> References: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> Message-ID: <060.371113ad6d85d203cfe3b2e2d4c5ec52@haskell.org> #12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: rwbarton Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: thomie => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 00:10:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 00:10:09 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables (was: Allow type synonym family application in instance head if it reduces away) In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.1111cfec8865a400ed1cdf03e3d9ad31@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 00:41:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 00:41:16 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it Message-ID: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The easiest way to illustrate this bug is this: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Foo where import Data.Kind (Type) blah :: forall (a :: k). k ~ Type => a -> a blah x = x }}} {{{ $ ghci Foo.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:8:43: error: • Expected a type, but ‘a’ has kind ‘k’ • In the type signature: blah :: forall (a :: k). k ~ Type => a -> a }}} I find this behavior quite surprising, especially since we have evidence that `k ~ Type` in scope! If the program above looks too contrived, consider a similar program that uses `Typeable`. I want to write something like this: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Foo where import Data.Kind (Type) import Data.Typeable foo :: forall k (a :: k) proxy. (Typeable k, Typeable a) => proxy a -> String foo _ = case eqT :: Maybe (k :~: Type) of Nothing -> "Non-Type kind" Just Refl -> case eqT :: Maybe (a :~: Int) of Nothing -> "Non-Int type" Just Refl -> "It's an Int!" }}} This exhibits the same problem. Despite the fact that we pattern-matched on a `Refl` of type `k :~: Type`, GHC refuses to consider the possibility that `a :~: Int` is well kinded, even though `(a :: k)`, and we learned from the first `Refl` that `k ~ Type`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 15:49:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 15:49:02 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows Message-ID: <047.4049513ac602284cecca46022b61971a@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.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: -------------------------------------+------------------------------------- Commit c8d995db5d743358b0583fe97f8113bf9047641e in ghc bumped the `time` submodule to the latest version 4eb06c0e (`time-1.8`). But it caused a Core Lint error while compiling `Distribution.Compat.Time`, in the Cabal library: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** : warning: In the expression: $wsystemToUTCTime (case lvl_sdDL of v_B1 { I# v_B2 -> v_B2 }) (case lvl_sdDM of v_B1 { W# v_B2 -> v_B2 }) This argument does not satisfy the let/app invariant: case lvl_sdDL of v_B1 { I# v_B2 -> v_B2 } }}} See https://phabricator.haskell.org/harbormaster/build/21371/ for the full build log. For now the submodule bumps have been reverted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 15:49:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 15:49:11 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.feeca52642e6f0d5068b27ba3cb907c0@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: (none) => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 16:03:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 16:03:53 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.af957ec61f9cbb9be46aa88c9cae5841@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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'm assuming this occurs only on Windows just because of lots of `#if defined mingw32_HOST_OS` in time and/or Cabal, and isn't Windows-specific in any more serious way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 16:06:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 16:06:57 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.0c99b539a34aa9c1fdc995b1bbef574a@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by Nolan): * Attachment "patchToLexer.x" added. I fixed this error. Now it works as expected. It passes tests but 3 of them report slight performance drop(I forgot their ids, now retesting...). Here's patch to ```compiler/parser/Lexer.x``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 16:12:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 16:12:08 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.4990cbfeb93f685ba35a4717cfe0df45@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by Nolan): * owner: (none) => Nolan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 18:06:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 18:06:10 -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.20ae1da565953ad91263d25a06e1dc76@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.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: | Phab:D1795 -------------------------------------+------------------------------------- Comment (by bgamari): I also noticed while looking at the early inline patch that `T11195`, which is derived from `OptCoercion`, also seems to take quite a long time (and consequently occasionally fails). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 18:34:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 18:34:33 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.3e95a0a1bbfde835beb189622dc71d16@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: rwbarton => (none) * cc: simonpj (added) Comment: Here is a self-contained reproducer with today's HEAD: {{{#!hs {-# LANGUAGE MagicHash #-} module Fl2 where import GHC.Exts magic# :: Int# -> Bool magic# x# = True {-# NOINLINE magic# #-} f :: Int# -> Int -> Int f x# n = length [ i | i@(I# i#) <- [0..n], magic# (remInt# x# 100000# -# i#) ] }}} When the expression `remInt# x# 100000#` gets floated out of the loop and replaced by {{{ case lvl_s2Tb of v_B1 { I# v_B2 -> v_B2 } }}} the surrounding application {{{ -# (case lvl_s2Tb of v_B1 { I# v_B2 -> v_B2 }) i#_a1ok }}} does not satisfy the let/app invariant. Interestingly my build of the "Join points" commit (Feb 1) does not float out the expression `remInt# x# 100000#`. That's a bit curious since it already contains the commit "Float unboxed expressions by boxing". So my guess is that one of "Another improvement to SetLevels" and "Fix SetLevels for join points" is responsible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 18:59:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 18:59:57 -0000 Subject: [GHC] #13339: Arbitrarily large expressions built out of cheap primops are not floated out Message-ID: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> #13339: Arbitrarily large expressions built out of cheap primops are not floated out -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- While investigating #13338 I was tripped up by the fact that GHC won't float out even a large expression like the product in {{{#!hs \i# -> magic# (x# *# 2# *# 2# *# 2# *# 2# *# 2# *# 2# *# 2# *# 2# -# i#) }}} The test involved here is `exprIsCheap`. The fact that `*#` is a cheap primop makes `exprIsCheap` think the whole expression is cheap; but clearly there must come some point where it would be better to float out the expression. Perhaps `exprIsCheap` should work more like `exprIsDupable`, and take the size of the expression into account. See related comments on `primOpIsCheap`, though this ticket is about saving runtime work, not code size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 19:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 19:00:11 -0000 Subject: [GHC] #13339: Arbitrarily large expressions built out of cheap primops are not floated out In-Reply-To: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> References: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> Message-ID: <062.b3de694e413a3171a96ba9e2ca619d63@haskell.org> #13339: Arbitrarily large expressions built out of cheap primops are not floated out -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 19:00:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 19:00:33 -0000 Subject: [GHC] #13339: Arbitrarily large expressions built out of cheap primops are not floated out In-Reply-To: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> References: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> Message-ID: <062.0390c1dd56a3739952b2289e0d823025@haskell.org> #13339: Arbitrarily large expressions built out of cheap primops are not floated out -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 rwbarton): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 19:32:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 19:32:37 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated Message-ID: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.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: -------------------------------------+------------------------------------- This module {{{#!hs module Two where f :: Int -> Int f n = n + 1 + 1 g :: Int -> Int g n = n + 1 + 1 }}} used to (in 8.0) optimize to a definition of `g` plus `f = g`. The Common sub-expression phase noticed `f` and `g` were equal. That doesn't happen any more in HEAD and we end up with two copies of the code. The Common sub-expression pass apparently still runs, it just doesn't succeed in removing one of the bindings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 19:39:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 19:39:45 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.c134ec0e348acc25a55d8c9448724b60@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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 guess this probably has to do with #11781, but it seems a bit silly that we can't handle this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 20:28:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 20:28:19 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.f2e69c8917a3a1527ccc8b0c794f4647@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 Nolan): Oops, it failed. Testing summary: {{{ Unexpected results from: TEST="T2762 BinaryLiterals0 T4029" SUMMARY for test run started at Sat Feb 25 19:00:27 2017 MSK 2:45:29 spent to go through 5766 total tests, which gave rise to 18079 test cases, of which 12034 were skipped 72 had missing libraries 5830 expected passes 140 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures 2 unexpected stat failures Unexpected failures: parser/should_run/BinaryLiterals0.run BinaryLiterals0 [exit code non-0] (normal) Unexpected stat failures: perf/space_leaks/T2762.run T2762 [stat too good] (normal) perf/space_leaks/T4029.run T4029 [stat not good enough] (ghci) }}} T4029: {{{ testsuite/tests/parser/should_run/BinaryLiterals0.hs:14:13: error: • Couldn't match expected type ‘(Int, Int)’ with actual type ‘a0 -> b0 -> (a0, b0)’ • Probable cause: ‘(-)’ is applied to too few arguments In the expression: (,) - 0 b0 In the expression: [(,) 0 b0, (,) 0 b1, (,) 0 b10, (,) 0 b11, ....] :: [(Int, Int)] In an equation for ‘lst’: lst = [(,) 0 b0, (,) 0 b1, (,) 0 b10, ....] :: [(Int, Int)] | 14 | , (,) -0b0, (,) -0b1, (,) -0b10, (,) -0b11 | ^^^^^^^^ ... and 3 similar }}} T2762: {{{ Expected T2762(normal) peak_megabytes_allocated: 3 +/-0% Lower bound T2762(normal) peak_megabytes_allocated: 3 Upper bound T2762(normal) peak_megabytes_allocated: 3 Actual T2762(normal) peak_megabytes_allocated: 2 Deviation T2762(normal) peak_megabytes_allocated: -33.3 % }}} T4029 {{{ peak_megabytes_allocated value is too high: Expected T4029(ghci) peak_megabytes_allocated: 76 +/-10% Lower bound T4029(ghci) peak_megabytes_allocated: 68 Upper bound T4029(ghci) peak_megabytes_allocated: 84 Actual T4029(ghci) peak_megabytes_allocated: 94 Deviation T4029(ghci) peak_megabytes_allocated: 23.7 % max_bytes_used value is too high: Expected T4029(ghci) max_bytes_used: 22016200 +/-5% Lower bound T4029(ghci) max_bytes_used: 20915390 Upper bound T4029(ghci) max_bytes_used: 23117010 Actual T4029(ghci) max_bytes_used: 27596592 Deviation T4029(ghci) max_bytes_used: 25.3 % }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 20:35:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 20:35:14 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.38c58a30c35e661de2fd7ef4eb59b0b2@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 mpickering): Nolan, perhaps you could put your patch up on [https://ghc.haskell.org/trac/ghc/wiki/Phabricator Phabricator] so that people can more easily help you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 20:50:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 20:50:12 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.d39f6e8c4a8c6af7e1ff111a5c2c5fdd@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 Nolan): Replying to [comment:6 mpickering]: > Nolan, perhaps you could put your patch up on [https://ghc.haskell.org/trac/ghc/wiki/Phabricator Phabricator] so that people can more easily help you? Thank you for advice, now it can be found [https://phabricator.haskell.org/D3212 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 21:14:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 21:14:10 -0000 Subject: [GHC] #13341: Lift constraint products Message-ID: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> #13341: Lift constraint products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I want to get a discussion going, could we lift constraint products automatically. Although not partially applicable, we can consider `(,)` as having kind {{{#!hs (,) :: Constraint -> Constraint -> Constraint }}} I propose also giving it kinds {{{#!hs (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) -- etc. }}} == Translation {{{#!hs (Eq, Num, Show) (Monad, Foldable) (Category, Profunctor) }}} gets turned into something like {{{#!hs class (c a, d a) => (c :&: d) a instance (c a, d a) => (c :&: d) a infixl 7 :&: Eq:&:Num:&:Show Monad:&:Foldable Category:&:Profunctor }}} == Uses Very often I need to be able to combine constraints. A small modification of [https://hackage.haskell.org/package/free- functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] {{{#!hs type c :~ d = forall xx. c x :- d xx class HasSuperClasses (c :: k -> Constraint) where type SuperClasses c :: k -> Constraint type SuperClasses c = c superClasses :: c :~ SuperClasses c containsSelf :: SuperClasses c :~ c instance HasSuperClasses Functor where superClasses :: Functor :~ Functor superClasses = Sub Dict containsSelf :: Functor :~ Functor containsSelf = Sub Dict instance HasSuperClasses Foldable where superClasses :: Foldable :~ Foldable superClasses = Sub Dict containsSelf :: Foldable :~ Foldable containsSelf = Sub Dict }}} I want to be able to write {{{#!hs instance HasSuperClasses Traversable where type Traversable = (Traversable, Functor, Foldable) superClasses :: Traversable :~ (Traversable, Functor, Foldable) superClasses = Sub Dict containsSelf :: (Traversable, Functor, Foldable) :~ Traversable containsSelf = Sub Dict }}} If this doesn't pose any difficulties I'll open a GHC proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:22:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:22:59 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr Message-ID: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- It seems that they should be outputted on stderr like other warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:27:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:27:26 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.b5cad29e082cd37f1954fd63afa657f2@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:40:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:40:01 -0000 Subject: [GHC] #13339: Arbitrarily large expressions built out of cheap primops are not floated out In-Reply-To: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> References: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> Message-ID: <062.46f29959e315232effd59b20bb32d050@haskell.org> #13339: Arbitrarily large expressions built out of cheap primops are not floated out -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 carter): * cc: carter.schonwald@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:52:17 -0000 Subject: [GHC] Batch modify: #12100, #12776, #12944, #13242, #7411, #11606, ... In-Reply-To: <255.59ee9b0df0555a16cdff6daea249dc9c@haskell.org> References: <255.59ee9b0df0555a16cdff6daea249dc9c@haskell.org> Message-ID: <270.326ef87217026f454d786105491e197c@haskell.org> Batch modification to #12100, #12776, #12944, #13242, #7411, #11606, #11959, #12150, #12425, #12610, #1851, #6132, #11525, #11731, #11827, #11954, #12021, #12090, #12193, #12234, #12737, #12846, #12885, #12921, #12940, #12985, #13025, #13035, #13043, #13050, #13056, #13083, #13135, #13245, #13246, #13285, #12055 by bgamari: milestone to 8.2.1 Comment: At this point it is rather unlikely that there will be an 8.0.3. Re-milestoning. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:52:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:52:41 -0000 Subject: [GHC] #13245: Default FD buffer size is not a power of 2 In-Reply-To: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> References: <042.5cc75f54ab6027ecf6dab82dc6b0e88f@haskell.org> Message-ID: <057.4c5961eadb5286bcf7fe920cb5a7955b@haskell.org> #13245: Default FD buffer size is not a power of 2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3115 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:52:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:52:53 -0000 Subject: [GHC] #13246: hPutBuf issues unnecessary empty write syscalls for large writes In-Reply-To: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> References: <042.5eee1c03d37732c479b2f30615e76ae1@haskell.org> Message-ID: <057.4fc46358080d7e4593f9acddaa3f9c64@haskell.org> #13246: hPutBuf issues unnecessary empty write syscalls for large writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13245 | Differential Rev(s): Phab:D3117 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:53:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:53:44 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.d24458e0d5d9c08cc17c66c4d47f8d2f@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T12776 Blocked By: | Blocking: Related Tickets: #12843 #12675 | Differential Rev(s): #12789 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:54:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:54:17 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.814a04ba197d1f43734e422a039a8e6f@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | deSugar/should_compile/T12944 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:54:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:54:33 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.bbeee7fd816e4476f5a16a9c46fa4f59@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12425 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 Feb 25 22:54:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:54:51 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.b226c3bb57d70daa774f4f641acf0c5e@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | UndecidableSuperClasses, plugin Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: #12780 | Differential Rev(s): Phab:D3105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:55:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:55:04 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.555d1635bc4bbfb2c7b2cbe7b3b3e3bc@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:55:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:55:19 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.138ad2b9d23c518a061e1941ce29f468@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/should_compile/T12234 Blocked By: | Blocking: Related Tickets: #13056, #13081 | 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 Feb 25 22:55:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:55:35 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS In-Reply-To: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> References: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> Message-ID: <065.e543c816ed4146dde24ebf4d68ac6d70@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12891 | Differential Rev(s): Phab:D2727 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:55:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:55:52 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.b85d08c62b53e5c128e69762a4dc410f@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc1 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:56:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:56:20 -0000 Subject: [GHC] #13218: <$ is bad in derived functor instances In-Reply-To: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> References: <045.eb11574f550c3963dc9b402732210fd3@haskell.org> Message-ID: <060.5ec1fb64f2e4f490605eb466883720d0@haskell.org> #13218: <$ is bad in derived functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.4.1 => 8.2.1 Comment: This was originally marked for the 8.4.1 milestone, but happily, it made it in time for 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 25 22:56:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Feb 2017 22:56:38 -0000 Subject: [GHC] Batch modify: #12776, #12944, #12425, #11525, #11731, #12234, ... In-Reply-To: <150.1634b137ae0506813a2a9db0b105c81a@haskell.org> References: <150.1634b137ae0506813a2a9db0b105c81a@haskell.org> Message-ID: <165.5a4e2ce9787eb22c17c9ef2108c201e5@haskell.org> Batch modification to #12776, #12944, #12425, #11525, #11731, #12234, #12846, #12885, #12921, #12985, #13025, #13035, #13043, #13050, #13056, #13083, #13135, #13285, #12055 by bgamari: Action: merged -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 00:10:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 00:10:04 -0000 Subject: [GHC] #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar Message-ID: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproducible with GHC 8.0.2 and HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Bug where import GHC.Exts type Bad = forall (v1 :: RuntimeRep) (a1 :: TYPE v). a1 }}} {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170223 for x86_64-unknown-linux): expectJust zonkTcTyVarToVar CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:53:27 in ghc:Maybes expectJust, called at compiler/typecheck/TcType.hs:1576:21 in ghc:TcType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 00:13:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 00:13:34 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.dc352762b6551c1c4dd35b9940f72129@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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 ghorn): This bug persists on GHC 8.0.1 at least, I run into it a few times a week using stack. Also see https://github.com/commercialhaskell/stack/issues/1842 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 00:21:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 00:21:59 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.f53a731d546ffc4b97ad112ac051aa54@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.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 RyanGlScott): After a quick audit, I found two `tcSplitSigmaTy`-related bugs: * http://git.haskell.org/ghc.git/blob/8f20844d3435094583db92a30550ca319d2be863:/compiler/hsSyn/HsUtils.hs#l843 When you type this into GHCi: {{{ λ> let a :: forall a b. (Num a, Num b) => (# a, b #); !a = (# 1, 2 #) }}} you get this error: {{{ You can't mix polymorphic and unlifted bindings !a = (# 1, 2 #) Probable fix: add a type signature }}} But if you type this instead: {{{ λ> let a :: forall a . (Num a) => forall b. (Num b) => (# a, b #); !a = (# 1, 2 #) }}} then GHCi panics! {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): dsLet: unlifted !a_a1Py = (# 1, 2 #) returnIO @ [()] (: @ () (unsafeCoerce# @ 'PtrRepLifted @ 'PtrRepLifted @ (forall a_a1P7. Num a_a1P7 => forall b_a1P8. Num b_a1P8 => (# a_a1P7, b_a1P8 #)) @ () a_a1P6) ([] @ ())) }}} * http://git.haskell.org/ghc.git/blob/8f20844d3435094583db92a30550ca319d2be863:/compiler/typecheck/TcExpr.hs#l2403 Compare this error message: {{{ λ> let f :: forall a b. (Monoid a, Monoid b) => Maybe a -> Maybe b; f _ = mempty λ> do { f; putChar 'a' } :30:6: error: • Couldn't match expected type ‘IO a1’ with actual type ‘Maybe a0 -> Maybe b0’ • Probable cause: ‘f’ is applied to too few arguments In a stmt of a 'do' block: f In the expression: do { f; putChar 'a' } In an equation for ‘it’: it = do { f; putChar 'a' } }}} with this one: {{{ λ> let f :: forall a. (Monoid a) => forall b. (Monoid b) => Maybe a -> Maybe b; f _ = mempty λ> do { f; putChar 'a' } :32:6: error: • Couldn't match expected type ‘IO a1’ with actual type ‘Maybe a0 -> Maybe b0’ • In a stmt of a 'do' block: f In the expression: do { f; putChar 'a' } In an equation for ‘it’: it = do { f; putChar 'a' } }}} The second one doesn't complain about `f` being applied to too few arguments! This is by no means an exhaustive list, as I only examine the parts of the codebase that I could make sense of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 07:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 07:02:35 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.df0ba36fb2f02b268747e5dcb601b0f7@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): After spending some time thinking through the proofs, I realized that goldfire's counterexample isn't actually valid, and we only need to do something complicated if we want to augment roles with a more fine-grained notion of injectivity. First, let's see how GHC rejects goldfire's example today, via hs-boot files: {{{ -- A.hs-boot {-# LANGUAGE RoleAnnotations #-} module A where data T a type role T nominal -- B.hs {-# LANGUAGE FlexibleContexts, RoleAnnotations #-} module B where import {-# SOURCE #-} A import Data.Coerce foo :: Coercible (T a) (T b) => a -> b foo x = x -- A.hs -- Doesn't really matter, but this will do: {-# LANGUAGE RoleAnnotations #-} module A where import B type role T nominal newtype T a = T Int }}} When we compile, we get: {{{ B.hs:6:9: error: • Could not deduce: a ~ b from the context: Coercible (T a) (T b) bound by the type signature for: foo :: Coercible (T a) (T b) => a -> b at B.hs:5:1-38 ‘a’ is a rigid type variable bound by the type signature for: foo :: forall a b. Coercible (T a) (T b) => a -> b at B.hs:5:1-38 ‘b’ is a rigid type variable bound by the type signature for: foo :: forall a b. Coercible (T a) (T b) => a -> b at B.hs:5:1-38 • In the expression: x In an equation for ‘foo’: foo x = x • Relevant bindings include x :: a (bound at B.hs:6:5) foo :: a -> b (bound at B.hs:6:1) }}} This is because GHC only applies the Co_Nth rule if the TyCon in question is *injective*, and abstract types are NOT injective. In fact, they're obviously not because I can implement an abstract data type with a newtype (as I do in my example), and as was demonstrated in the roles paper, it is unsound to Co_Nth on newtypes. So, all we have to do is make sure Backpack abstract data types are not injective (and indeed, they're not) and there's no problem. During our phone call, SPJ noticed that we could just unconditionally disable the Co_Nth rule if the TyCon was abstract or not (I didn't realize that they would already have been disabled), but we decided that the "abstract" strategy made more sense because you might *want* to say, "Hey, actually, I really do want you to be able to use Co_Nth on this parameter." Maybe it is worth investigating this, but for now I think it should be OK to merge Phab:D3123. ---- Since I've been thinking about this, let us talk about Co_Nth on newtypes. Consider the following program: {{{ newtype T a = MkT a }}} Given `T a ~R T b`, I might like to infer that `a ~R b`. If T were a data type, I could do this directly, but with newtypes, since Co_Nth doesn't apply, I have to take a roundabout route: I show `T a ~R a` and `T b ~R b` (by the newtype axiom) and then apply transitivity to pop out the final coercion. Under what situations would it be safe to apply Co_Nth here? Intuitively, the problem is that ascribed role for the parameter of T might not accurately describe how a is actually used in the body of the newtype, because it may have been weakened by subroling. That's bad news for Co_Nth, which really needs subroling to go "in the other direction." I conjecture the following system would be sound: 1. Associate every declaration with two sets of roles: one set that is applied in Co_TyConApp (call this the app-roles) and one that is applied for Co_Nth (call this the proj-roles). For data types, these are always the same. 2. For newtypes, the app-roles are specified by the existing role assignment rules. However, the proj-roles are specified by the role assignment rules with the subroling relationship *flipped*: i.e., phantom is a subrole of nominal (not the other way around.) 3. Proj-roles can be inferred like app-roles, but they are always consistent with proj-roles, and the subroling relationship is flipped. Here are a few examples: {{{ type app role T representational type proj role T representational newtype T a = MkT a -- T a ~R T b implies a ~R b type app role T nominal type proj role T representational -- NB: type proj role T nominal is NOT ALLOWED newtype T a = MkT a -- T a ~R T b implies a ~R b, BUT -- a ~R b is insufficient to prove T a ~R T b (you need a ~N b) type app role T nominal type proj role T phantom -- (representational and nominal not allowed) newtype T a = MkT Int -- T a ~R T b implies a ~P b (i.e. we don't learn anything) -- a ~N b implies T a ~R T b }}} To relate this back to the "abstract" role, what I have been calling an abstract role is actually a nominal app-role but phantom proj-role (i.e., the most flexible role of them all.) I ran into trouble trying to figure out how to infer abstractness, but I think if you make the language more expressive, that solves the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 14:30:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 14:30:29 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.010f35680fcfedf6dc7f050e34b5cb1e@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is an easy way to reproduce the problem. You need a compiler compiled with `-DDEBUG` (build flavour devel2 is easiest) and then `inplace/bin/ghc-stage2 -dcore-lint A.hs` {{{ module A where f :: [()] -> [()] f (x:xs) = x : f xs {-# INLINE f #-} }}} {{{ [1 of 1] Compiling A ( cltest.hs, cltest.o ) *** Core Lint warnings : in result of Occurrence analysis *** cltest.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f *** Core Lint warnings : in result of Simplifier *** cltest.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f *** Core Lint warnings : in result of Occurrence analysis *** cltest.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f *** Core Lint warnings : in result of Simplifier *** cltest.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f *** Core Lint warnings : in result of Tidy Core *** cltest.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f *** Core Lint warnings : in result of CorePrep *** cltest.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:25:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:25:11 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.188856d73e9c60a6892a1845bc5e69ec@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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 was trying to figure out how to avoid doing the floating out when the result would violate the let/app invariant, or possibly how to have `exprOkForSpeculation` look through the binding created by floating out, but hang on: if the expression was originally okay for speculation, then can't we just float it out as an unboxed value? That would be more efficient too. If we only ever do the boxing transformation to things that were not originally okay for speculation, then I think we can't break the let/app invariant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:27:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:27:48 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.af29fbfd28b6b03b60cdbd70defeff49@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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): Even this case doesn't get deduplicated: {{{#!hs f x = x g x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:27:54 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably Message-ID: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The Core string literals patch regresses compiler performance by nearly 5%. https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 We should really understand why this is; this is a huge regression for something that really shouldn't be costly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:28:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:28:26 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.f499053fde741cf2593af621c2ba6416@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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): * owner: (none) => bgamari * failure: None/Unknown => Compile-time performance bug * priority: normal => high Old description: > The Core string literals patch regresses compiler performance by nearly > 5%. > https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 > > We should really understand why this is; this is a huge regression for > something that really shouldn't be costly. New description: The Core string literals patch [[https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53feb3|regresses]] compiler performance by nearly 5%. We should really understand why this is; this is a huge regression for something that really shouldn't be costly. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:28:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:28:34 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.3873dbefb288f9bf7cebe9b7feacb6b3@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:29:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:29:44 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.d628cd809f313162f4561af3db652914@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:30:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:30:46 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.2525749cd83238e68c84599067c6cf30@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: highest => high Comment: This does get deduplicated though: {{{#!hs f = 0 :: Int g = 0 :: Int }}} so it's not totally broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:31:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:31:52 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.8c07c8502cea4bd682972f26da9ae282@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:41:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:41:37 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.53dd8e89f6f8a5bf6d5edd0a0fad662d@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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): It must be related to the new `Note [CSE for stable unfoldings]` as `f` and `g` get stable unfoldings in the cases in which CSE does not work and vanilla unfoldings in the case in which CSE does work. I have no idea why the unfoldings for `f` and `g` would ever be stable, though, reading the documentation for `InlineStable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 15:42:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 15:42:47 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.b4ff78cae3f8e6d20d8d8b6c3c43342a@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): I asked David look into this a few weeks back; he says that he may have seen duplicated strings in Core. `T5837` looks like it would be a good testcase to evaluate this issue with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:06:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:06:46 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.14324a278ad41f0a8ad3b19a0f491d12@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For your first example: this infelicity is by design, though I can't find documentation in the manual. Equality assumptions (such as your `k ~ Type`) come into scope only in an expression of that type, not later on in the same type. This design significantly eased the implementation. The second example should work -- that's a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:12:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:12:21 -0000 Subject: [GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes In-Reply-To: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> References: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> Message-ID: <065.d2457670797a25e86c00e69a1a317416@haskell.org> #13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4028 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Discussion on the GHC devs mailing list: https://mail.haskell.org/pipermail/ghc-devs/2017-February/013845.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:14:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:14:44 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.7323e47b97be4b578c30c34523894828@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Forgive me if this is a silly question, but why shouldn't the first example work? I know that the implementation details would significantly complicate the story, but my perspective, being able to write the first example would make a lot of code easier to write. An example of this that came up in real code is when [https://mail.haskell.org/pipermail/ghc- devs/2017-February/013850.html Edward Kmett tried to sketch out a solution] to #13327 on the ghc-devs mailing list, and attempted to write this code: {{{#!hs class (Typeable t, Typeable k) => DataIfStar (k :: t) where dataIf :: (t ~ Type) => proxy k -> (Data k => r) -> r }}} But this won't work, because `Data :: Type -> Constraint`, and GHC isn't able to conclude that `k :: t` is actually `k :: Type`, since the evidence that `t ~ Type` isn't being used when typechecking. If programs like these aren't supposed to typecheck by design, what is the workaround? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:17:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:17:33 -0000 Subject: [GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes In-Reply-To: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> References: <050.56300a6b377c123491f18a3cc7ff2980@haskell.org> Message-ID: <065.1beaaf85a3572de2c01701bd5cc94a5c@haskell.org> #13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4028 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Edward Kmett laid out an interesting (albeit not terribly practical) proposal for cleaning up the current story in https://mail.haskell.org/pipermail/ghc-devs/2017-February/013850.html. Sadly, his code doesn't actually typecheck due to what I believe is a corollary of #13337. I came up with an even grosser proposal in https://mail.haskell.org/pipermail/ghc-devs/2017-February/013852.html that //does// typecheck, but with emphasis on the "even grosser" part. There's certainly no way I'd want `Data.Data` to adopt that approach as-is. I need to think more on how I can take the programming patterns in these two proposals and clean them up into something palatable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:21:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:21:39 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.afc4c3a6fc2fd511b566718721dcd884@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another way to phrase my question is: I don't see what the distinction between the first and second examples is. After all, you can rewrite the second example like this: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Foo where import Data.Kind (Type) import Data.Typeable foo :: forall k (a :: k) proxy. (Typeable k, Typeable a) => proxy a -> String foo _ = case eqT :: Maybe (k :~: Type) of Nothing -> "Non-Type kind" Just Refl -> go_on eqT where go_on :: Maybe (a :~: Int) -> String go_on Nothing = "Non-Int type" go_on (Just Refl) = "It's an Int!" }}} Now the equality assumption isn't coming into scope "only in an expression of that type", it's coming into scope in a type signature! So again, unless I'm misunderstanding something, I strongly suspect that fixing the second program would naturally lend itself towards fixing the first program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:42:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:42:04 -0000 Subject: [GHC] #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar In-Reply-To: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> References: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> Message-ID: <065.c96fb931311e89c2b5b59bb330430482@haskell.org> #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't have more time to look into precisely why this is getting through the cracks, but that type should be rejected by `TcValidity.check_type`. Look for the call to `forAllEscapeErr`. In short, that type is malformed because it's kind must mention `v`, which is out-of-scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:45:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:45:31 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.cef27b8eb60cf456fcb9cae0538b53e5@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.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): Replying to [comment:3 RyanGlScott]: > When you type this into GHCi: > > {{{ > λ> let a :: forall a b. (Num a, Num b) => (# a, b #); !a = (# 1, 2 #) > }}} > > you get this error: > > {{{ > You can't mix polymorphic and unlifted bindings > !a = (# 1, 2 #) > Probable fix: add a type signature > }}} I'm confused. That's not an unlifted binding! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:51:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:51:26 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.60e23e69c880d6863a3737b544f23866@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"41e54b4b1a2934364759edcf77ba1f5b03a4098f/ghc" 41e54b4b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="41e54b4b1a2934364759edcf77ba1f5b03a4098f" Load dependent dlls. When the `GCC` driver envokes the pipeline a `SPEC` is used to determine how to configure the compiler and which libraries to pass along. For Windows/mingw, this specfile is https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h This has a lot of interesting things that we need to emulate in order to be able to link as many things out of the box as GCC. In particular this is why you never need to specify `-lgcc_s` when compiling, but you do when using `GHCi`. Unfortunately due to time constraints I can't set up the framework required in `GHC` to do this before the feature freeze. So I suggest this alternate implementation: When we load a dll, also bring it's dependencies into scope of the interpeter. This has pros and cons. Pro is, we'll fix many packages on hackage which specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which will bring `libgcc` into scope. The downside is, we'll be more lenient than GCC, in that the interpreter will link much easier since it has implicit dependencies in scope. Whereas for compilation to work you will have to specify it as an argument to GHC. This will make the Windows runtime linker more consistent with the unix ones. The difference in semantics came about because of the differences between `dlsym` and `GetProcAddress`. The former seems to search the given library and all it's dependencies, while the latter only searches the export table of the library. So we need some extra manual work to search the dependencies which this patch provides. Test Plan: ``` ./validate ``` ``` $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS -lstdc++ 2>&1 | grep "Loading dependency" ``` ``` $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS -Dl -RTS 2>&1 | grep "Loading dependency" Loading dependency *.exe -> GDI32.dll. Loading dependency GDI32.dll -> ntdll.dll. Loading dependency *.exe -> KERNEL32.dll. Loading dependency KERNEL32.dll -> KERNELBASE.dll. Loading dependency *.exe -> msvcrt.dll. Loading dependency *.exe -> SHELL32.dll. Loading dependency SHELL32.dll -> USER32.dll. Loading dependency USER32.dll -> win32u.dll. Loading dependency *.exe -> WINMM.dll. Loading dependency WINMM.dll -> WINMMBASE.dll. Loading dependency *.exe -> WSOCK32.dll. Loading dependency WSOCK32.dll -> WS2_32.dll. Loading dependency WS2_32.dll -> RPCRT4.dll. Loading dependency libstdc++-6.dll -> libwinpthread-1.dll. Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll. ``` Trac tickets: #13093, #13189 Reviewers: simonmar, rwbarton, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3028 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:51:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:51:26 -0000 Subject: [GHC] #13189: Implement same specification as GHC spec file for mingw32 In-Reply-To: <044.0d7b956789dcbf134cbfab9b7fb7505a@haskell.org> References: <044.0d7b956789dcbf134cbfab9b7fb7505a@haskell.org> Message-ID: <059.7f6ac50ff9545d649c0eaeef9395e77d@haskell.org> #13189: Implement same specification as GHC spec file for mingw32 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"41e54b4b1a2934364759edcf77ba1f5b03a4098f/ghc" 41e54b4b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="41e54b4b1a2934364759edcf77ba1f5b03a4098f" Load dependent dlls. When the `GCC` driver envokes the pipeline a `SPEC` is used to determine how to configure the compiler and which libraries to pass along. For Windows/mingw, this specfile is https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h This has a lot of interesting things that we need to emulate in order to be able to link as many things out of the box as GCC. In particular this is why you never need to specify `-lgcc_s` when compiling, but you do when using `GHCi`. Unfortunately due to time constraints I can't set up the framework required in `GHC` to do this before the feature freeze. So I suggest this alternate implementation: When we load a dll, also bring it's dependencies into scope of the interpeter. This has pros and cons. Pro is, we'll fix many packages on hackage which specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which will bring `libgcc` into scope. The downside is, we'll be more lenient than GCC, in that the interpreter will link much easier since it has implicit dependencies in scope. Whereas for compilation to work you will have to specify it as an argument to GHC. This will make the Windows runtime linker more consistent with the unix ones. The difference in semantics came about because of the differences between `dlsym` and `GetProcAddress`. The former seems to search the given library and all it's dependencies, while the latter only searches the export table of the library. So we need some extra manual work to search the dependencies which this patch provides. Test Plan: ``` ./validate ``` ``` $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS -lstdc++ 2>&1 | grep "Loading dependency" ``` ``` $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS -Dl -RTS 2>&1 | grep "Loading dependency" Loading dependency *.exe -> GDI32.dll. Loading dependency GDI32.dll -> ntdll.dll. Loading dependency *.exe -> KERNEL32.dll. Loading dependency KERNEL32.dll -> KERNELBASE.dll. Loading dependency *.exe -> msvcrt.dll. Loading dependency *.exe -> SHELL32.dll. Loading dependency SHELL32.dll -> USER32.dll. Loading dependency USER32.dll -> win32u.dll. Loading dependency *.exe -> WINMM.dll. Loading dependency WINMM.dll -> WINMMBASE.dll. Loading dependency *.exe -> WSOCK32.dll. Loading dependency WSOCK32.dll -> WS2_32.dll. Loading dependency WS2_32.dll -> RPCRT4.dll. Loading dependency libstdc++-6.dll -> libwinpthread-1.dll. Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll. ``` Trac tickets: #13093, #13189 Reviewers: simonmar, rwbarton, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3028 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:51:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:51:26 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows In-Reply-To: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> References: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> Message-ID: <065.63fd45535c5f4e08cad24399c4c090c0@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3154 Wiki Page: | Phab:D3155 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9968502d075e3a714913e14cd96a7d6b7ac7b5e7/ghc" 9968502d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9968502d075e3a714913e14cd96a7d6b7ac7b5e7" Make list of deprecated symbols on Windows weak. We have a unfortunate workaround in place for the fact that most packages out there use POSIX names for symbols even on Windows. This means that we have to recognize e.g. both `_ungetch` and `ungetch`. The former is the actual symbol name on windows and the latter is the POSIX variant. The problem is that on normal windows programs `ungetch` should not be in the global namespace. To work around this, we now mark the deprecated symbols as weak symbols in the global namespace. This provides the flexibility we need: * If you use the symbol without defining it, we assume you meant to use the POSIX variant. * If you actually define the symbol, we'll hence forth use that definition and assume you didn't mean to use POSIX code. This is how MingW64's wrapper also works. This requires D3028. Fixes #13210. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3154 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 16:53:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 16:53:04 -0000 Subject: [GHC] #13311: Audit shady uses of tcSplitSigmaTy In-Reply-To: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> References: <050.72458ab96a239fb6dc8ceaeb2c02afab@haskell.org> Message-ID: <065.6b34152ec26c54128f8a7901277ed89f@haskell.org> #13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.4.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 RyanGlScott): Replying to [comment:4 goldfire]: > I'm confused. That's not an unlifted binding! Good point. But the main point is that there is a discrepancy that can be unveiled simply by nesting `forall`s, not that the error message is off. (BTW, #9140 is where this error message originally comes from.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:05:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:05:05 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows In-Reply-To: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> References: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> Message-ID: <065.c6536b6e1ff1ebd5cdc660627aa41ea3@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3154 Wiki Page: | Phab:D3155 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:05:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:05:30 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.a4a5e41eb0ac5305d4bb5afc83b0f172@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I like comment:10. I had forgotten that abstract types were not injective w.r.t. representational equality. Is this because GHC 8.0 (and below) allows an hs-boot file to say `data` where the implementing module says `newtype`? I can't think of another reason. In any case, this is a happy ending to your story. As for the app-roles vs. proj-roles: very interesting. Currently, the solver runs into a problem when proving, say, `N a ~R N b`, where `N` is a newtype whose constructor is in scope: should we unwrap the newtype? Or use decomposition? (Note that this is somewhat the converse problem to the discussion above. Here we're trying to ''prove'' `N a ~R N b`; previous discussion assumed `N a ~R N b` and was trying to learn about `a` and `b`.) I forget exactly what happens here -- it's all in the [http://cs.brynmawr.edu/~rae/papers/2016/coercible-jfp/coercible-jfp.pdf paper]. But I do remember that the resolution was dissatisfyingly incomplete in the case of recursive newtypes. Perhaps Edward's idea in comment:10 -- separate out two sets of roles -- provides a better way forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:06:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:06:16 -0000 Subject: [GHC] #13113: Runtime linker errors with CSFML on Windows In-Reply-To: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> References: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> Message-ID: <065.e34a7995463062ecfbaada841be229d7@haskell.org> #13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13093 | Differential Rev(s): ​Phab:D3028 Wiki Page: | Phab:D3026 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:16:15 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.a391b27bfe38123b7b87766564b98968@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The problem is that `a ~ b` is a ''lifted'' type. That is, it contains bottom. So, when you write `forall k (a :: k). k ~ Type => a -> a` or some such, there's no place to check whether the proof of `k ~ Type` is valid before you use it. When an expression intervenes, then GHC can insert a `case` to evaluate the equality proof box to find the real primitive (`~#`) equality inside. Some notes on this issue (intended solely as notes to self, so YMMV) are [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality here]. So I don't agree that solving (2) will help with (1) here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:23:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:23:03 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.57cf3694b01a13feba9f575197f9a1dd@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13338 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3217 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * testcase: => simplCore/should_compile/T13338 * differential: => Phab:D3217 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:23:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:23:37 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.43782772cadd5349f4aa86be343ee72f@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I completely overlooked bottoming equalities. Thanks for the reference. In light of this, my "equivalent" program in comment:3 is not equivalent at all, since the `k ~ Type` evidence in `go_on` isn't known //a priori// to terminate, whereas in the original program, the equality is known not to bottom out by pattern matching on `Refl`. So I suppose a better title for this bug would be "GHC doesn't think a type is of kind *, despite having Typeable-induced evidence for it", and the first program would be related to Dependent Haskell, which is, erm, in progress :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 17:30:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 17:30:07 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.013ec14d9cf0a6db1bdbf53d36d1104c@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Theorem (Progress): For all research projects ρ, either ρ is published, or there exists a day δ such that ρ steps to ρ'. Proof: Fix a given research project ρ. We now have two cases: either ρ is published, which trivially implies progress; or we must produce a day δ in which ρ will advance. We are done, choosing δ = tomorrow. QED. So, yes, Dependent Haskell is in progress. And, yes, I agree with your other analysis in comment:5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 19:56:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 19:56:34 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.31f3d4ab12078c0491af84023538f5fe@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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 Ben Gamari ): In [changeset:"517ad201ff6ca1ef0d78c22f31de747709fb7c99/ghc" 517ad20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="517ad201ff6ca1ef0d78c22f31de747709fb7c99" Add testcase for #13340 Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3215 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 19:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 19:57:44 -0000 Subject: [GHC] #13345: GHC 8 type checker regression Message-ID: <051.bb48563af475a457fe8c108680ecf0a9@haskell.org> #13345: GHC 8 type checker regression -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: type | Operating System: Unknown/Multiple annotation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.1/2 needs a type annotation where GHC 7.8 can do without: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeSynonymInstances, FlexibleInstances, MultiParamTypeClasses #-} data T = Var | App T T data S = S class Tr a b where tr :: a -> b tr = undefined instance Tr S T where instance Tr a b => Tr [a] [b] where test :: [S] -> T test es = let -- es' :: [T] -- This type annotation is not needed by ghc-7.8 es' = tr es in foldl App Var es' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 20:18:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 20:18:03 -0000 Subject: [GHC] #13345: GHC 8 type checker regression In-Reply-To: <051.bb48563af475a457fe8c108680ecf0a9@haskell.org> References: <051.bb48563af475a457fe8c108680ecf0a9@haskell.org> Message-ID: <066.4cafbdca0ef23d4bba7445a34a3a01a6@haskell.org> #13345: GHC 8 type checker regression -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: type Resolution: invalid | annotation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: First, note that this started to error on GHC 7.10.3, not GHC 8.0: {{{ Bug.hs:17:11: No instance for (Tr [S] (t0 T)) arising from a use of ‘tr’ The type variable ‘t0’ is ambiguous Relevant bindings include es' :: t0 T (bound at Bug.hs:17:5) Note: there is a potential instance available: instance Tr a b => Tr [a] [b] -- Defined at Bug.hs:12:10 In the expression: tr es In an equation for ‘es'’: es' = tr es In the expression: let es' = tr es in foldl App Var es' Bug.hs:18:6: No instance for (Foldable t0) arising from a use of ‘foldl’ The type variable ‘t0’ is ambiguous Relevant bindings include es' :: t0 T (bound at Bug.hs:17:5) Note: there are several potential instances: instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ ...plus three others In the expression: foldl App Var es' In the expression: let es' = tr es in foldl App Var es' In an equation for ‘test’: test es = let es' = tr es in foldl App Var es' }}} That `No instance for (Foldable t0)` reveals why: the type signature of `foldl` was generalized from: {{{#!hs foldl :: (b -> a -> b) -> b -> [a] -> b }}} to: {{{#!hs foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b }}} Indeed, if you locally redefine `foldl` to use the former type signature: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeSynonymInstances, FlexibleInstances, MultiParamTypeClasses #-} import Prelude hiding (foldl) import qualified Prelude data T = Var | App T T data S = S class Tr a b where tr :: a -> b tr = undefined instance Tr S T where instance Tr a b => Tr [a] [b] where foldl :: (b -> a -> b) -> b -> [a] -> b foldl = Prelude.foldl test :: [S] -> T test es = let es' = tr es in foldl App Var es' }}} Then it will typecheck on GHC 7.10 and 8.0. Alternatively, you can just give a type signature to `es'`, which is arguably cleaner. So this isn't a change in typechecker behavior at all, just a library design choice. See also [https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysNoinstanceforFoldable...arisingfromtheuseof... this], which details what would happen if you tried to use a `Foldable` function on a `String` with `OverloadedStrings` on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:14:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:14:08 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.ff654f23bdf8a5d60e8f498c40d4dd8a@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): > Is this because GHC 8.0 (and below) allows an hs-boot file to say data where the implementing module says newtype? Yep. > Currently, the solver runs into a problem when proving, say, N a ~R N b, where N is a newtype whose constructor is in scope: should we unwrap the newtype? Or use decomposition? Ah, this is very interesting (also, thank you for telling me about the journal paper; I didn't realize you had both an extended mix and a journal copy). What we would like to do is two things: 1. Allow decomposition on newtype givens (currently disallowed because Co_Nth doesn't work on newtypes). If we use the proj-roles here, that should solve the soundness problem. 2. Do decomposition BEFORE unwrapping, so that if we hit `FixEither Age ~R FixEither Int`, we immediately jump to `Age ~R Int`, rather than uselessly infinite loop on the newtype unwrapping. (2) is a bit trickier. Suppose when you have something like this: {{{ type app role T nominal type proj role T phantom newtype T a = MkT a }}} What "roles" should I use in the decomposition here, if I am trying to prove `T Int ~R T Age`? Clearly, the only sound and complete choice is representational. Ignoring proj-roles for a moment, the reason we must flatten before we decompose, even today, is because if we decomposed the constraint above, we would end up with `Int ~N Age` which is unsolvable. So, it seems to me, that eager decomposition will go wrong UNLESS you know the "exact" roles of the newtype (the role computation without any subroling). The subroling doesn't affect soundness but it does affect completeness if your constraint solver doesn't backtrack (which ours does not.) I'm also not sure if just (2) is guaranteed to get us to the point where newtype decomposition will actually apply, but the simple examples I thought of seemed to work (including the one in the paper.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:18:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:18:31 -0000 Subject: [GHC] #13325: Binary distributions produced from cross-compiled stage2 are broken In-Reply-To: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> References: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> Message-ID: <061.2365fdd2a3c5f64f125f99e760f8b5c0@haskell.org> #13325: Binary distributions produced from cross-compiled stage2 are broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8910 | Differential Rev(s): Phab:D3187 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a7eeb607e62bb360327d834fc6dd5ea6195ae825/ghc" a7eeb607/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7eeb607e62bb360327d834fc6dd5ea6195ae825" build system: Persist CrossCompiling in binary distributions The build system uses the CrossCompiling variable to decide whether or not we should build various packages that must be built using the compiler. Consequently, it is important that we persist its value in the binary distribution so we know during `make install` not to go looking for files that would have been built for these packages. Failing to do this causes #13325. Test Plan: Cross compile, `make binary-dist`, and try installing the binary distribution on the target Reviewers: hvr, austin, trofi, rwbarton Reviewed By: trofi, rwbarton Subscribers: carter, trofi, rwbarton, erikd, thomie, snowleopard, davean Differential Revision: https://phabricator.haskell.org/D3187 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:24:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:24:48 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.2807648fa10dd2d5b54f05aa9205d87f@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): I suspect the solution will be to expand the "box-demand analysis" described in the demand analysis paper ever so slightly. Instead of choosing between just passing the box/tuple and passing (some of) its contents, I think we want to add a third option: pass the box ''and'' (some of) its contents. This is a good option to have when we only need the box sometimes, and indeed is even important in cases where we ''always'' (eventually) need the box: {{{#!hs f :: Int -> [Int] -> [Int] f !n [] = [n] f n (x : xs) | x > 1000 = n : f x xs | otherwise = x : f n xs }}} This simplifies to {{{ Rec { -- RHS size: {terms: 41, types: 48, coercions: 0, joins: 0/0} $wf :: Int# -> [Int] -> (# Int, [Int] #) $wf = \ (ww_s2b5 :: Int#) (w_s2b2 :: [Int]) -> case w_s2b2 of { [] -> (# I# ww_s2b5, [] #); : ipv_s29V ipv1_s29W -> case ipv_s29V of wild1_a2a8 { I# x_a2aa -> case tagToEnum# (># x_a2aa 1000#) of { False -> (# wild1_a2a8, case $wf ww_s2b5 ipv1_s29W of { (# ww2_s2bb, ww3_s2bc #) -> : ww2_s2bb ww3_s2bc } #); True -> (# I# ww_s2b5, case $wf x_a2aa ipv1_s29W of { (# ww2_s2bb, ww3_s2bc #) -> : ww2_s2bb ww3_s2bc } #) } } } end Rec } -- RHS size: {terms: 13, types: 15, coercions: 0, joins: 0/0} f :: Int -> [Int] -> [Int] f = \ (w_s2b1 :: Int) (w1_s2b2 :: [Int]) -> case w_s2b1 of { I# ww1_s2b5 -> case $wf ww1_s2b5 w1_s2b2 of { (# ww3_s2bb, ww4_s2bc #) -> : ww3_s2bb ww4_s2bc } } }}} Whoops! Even this keeps losing boxes it ends up needing again. Indeed, this example demonstrates that we can lose a bunch of boxes when we will ''always'' end up needing to reconstruct them. A better transformation would give `$wf` a type like `Int# -> Int -> [Int] -> (# Int, [Int] #)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:29:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:29:24 -0000 Subject: [GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886 In-Reply-To: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> References: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> Message-ID: <061.52c1f65225708405e06e723c7da64961@haskell.org> #10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9058 | Differential Rev(s): Phab:D3188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was merged in ad617a3edf832b5368146e0bbf0cf2780d9355e1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:30:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:30:44 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.292916dfc80fc3351d9158eee823e1af@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: If I'm not mistaken this is now resolved by Phab:D3028. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:32:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:32:53 -0000 Subject: [GHC] #13325: Binary distributions produced from cross-compiled stage2 are broken In-Reply-To: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> References: <046.8c465abc8f51e6fb55479b97ca5dbbb6@haskell.org> Message-ID: <061.588650b8c845f235b595d061fb1a4983@haskell.org> #13325: Binary distributions produced from cross-compiled stage2 are broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8910 | Differential Rev(s): Phab:D3187 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:34:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:34:50 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.d685a8b3998a896b0824127d8ffc20ec@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) * status: closed => new * resolution: fixed => Comment: No it requires Phab:D3082 (msvc generates files with extension .obj). But also requires a final patch that I have yet to write. That's what I meant in comment:10 :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:34:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:34:57 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.633b2ade84aa80a1150546b50d729c8b@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3090 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 21:35:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 21:35:02 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.727688eddd03100faf3edb80493b53c7@haskell.org> #13093: Runtime linker chokes on object files created by MSVC++ -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13103 | Differential Rev(s): Phab:D3026 Wiki Page: | Phab:D3027 Phab:D3082 Phab:D3028 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 22:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 22:26:21 -0000 Subject: [GHC] #13171: panic on negative literal in case on Word In-Reply-To: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> References: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> Message-ID: <062.e022cc77332b1a1ac8955ad33e4052b7@haskell.org> #13171: panic on negative literal in case on Word -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6dfc5ebf70df8f0fdccc5004d914b777f21f3b72/ghc" 6dfc5eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6dfc5ebf70df8f0fdccc5004d914b777f21f3b72" Ensure that Literals are in range This commit fixes several bugs related to case expressions involving numeric literals which are not in the range of values of their (fixed-width, integral) type. There is a new invariant on Literal: The argument of a MachInt[64] or MachWord[64] must lie within the range of the corresponding primitive type Int[64]# or Word[64]#, as defined by the target machine. This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping the argument to the target type's range if necessary. Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245 T10246" Trac issues: #9533, #10245, #10246, #13171 Reviewers: simonmar, simonpj, austin, bgamari, nomeata Reviewed By: bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D810 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 22:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 22:26:21 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.abf7853d0467e99ce963e2467221767e@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3090 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0d86aa5904e5a06c93632357122e57e4e118fd2a/ghc" 0d86aa59/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d86aa5904e5a06c93632357122e57e4e118fd2a" Add support for concurrent package db access and updates Trac issues: #13194 Reviewers: austin, hvr, erikd, bgamari, dfeuer, duncan Subscribers: DemiMarie, dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3090 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 22:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 22:26:21 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.c2cfc201d0542722b137f6b2fa005d90@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6dfc5ebf70df8f0fdccc5004d914b777f21f3b72/ghc" 6dfc5eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6dfc5ebf70df8f0fdccc5004d914b777f21f3b72" Ensure that Literals are in range This commit fixes several bugs related to case expressions involving numeric literals which are not in the range of values of their (fixed-width, integral) type. There is a new invariant on Literal: The argument of a MachInt[64] or MachWord[64] must lie within the range of the corresponding primitive type Int[64]# or Word[64]#, as defined by the target machine. This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping the argument to the target type's range if necessary. Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245 T10246" Trac issues: #9533, #10245, #10246, #13171 Reviewers: simonmar, simonpj, austin, bgamari, nomeata Reviewed By: bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D810 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 22:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 22:26:21 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.fe1dd0eebfb43ab9cf86d1c55a3d8e86@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | 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): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6dfc5ebf70df8f0fdccc5004d914b777f21f3b72/ghc" 6dfc5eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6dfc5ebf70df8f0fdccc5004d914b777f21f3b72" Ensure that Literals are in range This commit fixes several bugs related to case expressions involving numeric literals which are not in the range of values of their (fixed-width, integral) type. There is a new invariant on Literal: The argument of a MachInt[64] or MachWord[64] must lie within the range of the corresponding primitive type Int[64]# or Word[64]#, as defined by the target machine. This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping the argument to the target type's range if necessary. Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245 T10246" Trac issues: #9533, #10245, #10246, #13171 Reviewers: simonmar, simonpj, austin, bgamari, nomeata Reviewed By: bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D810 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 22:26:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 22:26:21 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.799d1366d76b17c301db5b4222b9848f@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: 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: #9533 | Differential Rev(s): Phab:D810 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6dfc5ebf70df8f0fdccc5004d914b777f21f3b72/ghc" 6dfc5eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6dfc5ebf70df8f0fdccc5004d914b777f21f3b72" Ensure that Literals are in range This commit fixes several bugs related to case expressions involving numeric literals which are not in the range of values of their (fixed-width, integral) type. There is a new invariant on Literal: The argument of a MachInt[64] or MachWord[64] must lie within the range of the corresponding primitive type Int[64]# or Word[64]#, as defined by the target machine. This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping the argument to the target type's range if necessary. Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245 T10246" Trac issues: #9533, #10245, #10246, #13171 Reviewers: simonmar, simonpj, austin, bgamari, nomeata Reviewed By: bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D810 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 22:48:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 22:48:57 -0000 Subject: [GHC] #13331: Worker/wrapper can lead to sharing failure In-Reply-To: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> References: <045.798fd7eeb6c6faff35d21c533c53cb7b@haskell.org> Message-ID: <060.3bd6c43a20ed8aae9c57e47ec145d731@haskell.org> #13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 dfeuer): Ah, I see better now. My tiny list example can probably be fixed relatively easily using a "just pass both" approach, but my real-life example involves some knowledge the compiler doesn't have: that we tend to have the box already and/or we end up needing the box, and that the cost of losing sharing here is higher than it may look. That application dependence seems to argue in favor of a pragma-based solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:15:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:15:12 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.e02fd9b6143d6d04c8261aeaab2a7d17@haskell.org> #1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"5c95e6b7c2790c192720ba5a533d6d11fad570f8/ghc" 5c95e6b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5c95e6b7c2790c192720ba5a533d6d11fad570f8" Remove outdated information about main() in HSrts (#1) The main method is not contained in HSrts so the removed section is no longer valid. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:15:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:15:12 -0000 Subject: [GHC] #12223: Get rid of extra_files.py In-Reply-To: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> References: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> Message-ID: <060.dac0ca15123ba2f7234c6cb35f0063b4@haskell.org> #12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: rwbarton Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3415bcaa0b1903b5e12dfaadb5b774718e406eab/ghc" 3415bca/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3415bcaa0b1903b5e12dfaadb5b774718e406eab" tests: remove extra_files.py (#12223) The script I used is included as testsuite/driver/kill_extra_files.py, though at this point it is for mostly historical interest. Some of the tests in libraries/hpc relied on extra_files.py, so this commit includes an update to that submodule. One test in libraries/process also relies on extra_files.py, but we cannot update that submodule so easily, so for now we special-case it in the test driver. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:19:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:19:11 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.aeaa81ec1ee1ed53d63f10fcf5b4fb65@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: 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 bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:19:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:19:28 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.231c7f411196d7b0d2a5126e0c5f63eb@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:19:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:19:44 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.1727ed5c9513201c89e45a5204a8ea62@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: 8.2.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: #9533 | Differential Rev(s): Phab:D810 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Old description: > I found this long-standing bug while investigating #10245: > > Consider this code: > {{{ > f1 :: Int -> String > f1 n = case n of > 0 -> "bar" > 0x10000000000000000 -> "foo" > _ -> "c" > {-# NOINLINE f1 #-} > > g1 :: Int -> String > g1 n = if n == 0 then "bar" else > if n == 0x10000000000000000 then "foo" else > "c" > {-# NOINLINE g1 #-} > > f2 :: Int -> String > f2 n = case n of > 0x10000000000000000 -> "foo" > 0 -> "bar" > _ -> "c" > {-# NOINLINE f2 #-} > > g2 :: Int -> String > g2 n = if n == 0x10000000000000000 then "foo" else > if n == 0 then "bar" else > "c" > {-# NOINLINE g2 #-} > > main = do > let i = read "0" :: Int > print (f1 i) > print (g1 i) > print (f2 i) > print (g2 i) > }}} > > According to the report, `f1` should behave like `g1` and `f2` should > behave like `g2`. But that is not the case: I get > {{{ > "foo" > "bar" > "foo" > "foo" > }}} > > The reason is that the branches are sorted, to create fancy code for it, > but this does not take into account that `0x10000000000000000 = 0`, at > least for `Int`. > > This bug is present also in 7.8.4, and not (directly) related to my > CmmSwitch code: It can also be observed with interpreted code, so the fix > must happen earlier. New description: I found this long-standing bug while investigating #10245: Consider this code: {{{#!hs f1 :: Int -> String f1 n = case n of 0 -> "bar" 0x10000000000000000 -> "foo" _ -> "c" {-# NOINLINE f1 #-} g1 :: Int -> String g1 n = if n == 0 then "bar" else if n == 0x10000000000000000 then "foo" else "c" {-# NOINLINE g1 #-} f2 :: Int -> String f2 n = case n of 0x10000000000000000 -> "foo" 0 -> "bar" _ -> "c" {-# NOINLINE f2 #-} g2 :: Int -> String g2 n = if n == 0x10000000000000000 then "foo" else if n == 0 then "bar" else "c" {-# NOINLINE g2 #-} main = do let i = read "0" :: Int print (f1 i) print (g1 i) print (f2 i) print (g2 i) }}} According to the report, `f1` should behave like `g1` and `f2` should behave like `g2`. But that is not the case: I get {{{ "foo" "bar" "foo" "foo" }}} The reason is that the branches are sorted, to create fancy code for it, but this does not take into account that `0x10000000000000000 = 0`, at least for `Int`. This bug is present also in 7.8.4, and not (directly) related to my CmmSwitch code: It can also be observed with interpreted code, so the fix must happen earlier. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:20:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:20:02 -0000 Subject: [GHC] #13171: panic on negative literal in case on Word In-Reply-To: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> References: <047.15bfc176b50e0ce287f07fd3708d2096@haskell.org> Message-ID: <062.f9adccb8a319c4ea4410eb3cd6d001ae@haskell.org> #13171: panic on negative literal in case on Word -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:20:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:20:30 -0000 Subject: [GHC] #12223: Get rid of extra_files.py In-Reply-To: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> References: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> Message-ID: <060.b39a52bf33f91a1ad70113eac9ce2fd8@haskell.org> #12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: rwbarton Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:20:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:20:50 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.3c86810b1c15913d7862a6fd41bd504c@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3090 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:21:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:21:59 -0000 Subject: [GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries In-Reply-To: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> References: <046.c4b0ff74c04d54084f00280eae4236c4@haskell.org> Message-ID: <061.e742d11ec137122fa6188dedf4ecb937@haskell.org> #13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3143 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Alright, I will close this in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 26 23:22:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Feb 2017 23:22:35 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.91e426e8fed01cabb75285054fdeec79@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: fixed | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3144 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged in 2aac0ba111e0b09b1ffe4886b4a638042aae57d4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 00:03:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 00:03:37 -0000 Subject: [GHC] #13335: Non-abstract types also have skolem nature In-Reply-To: <045.1cd550b891f74e462b3401513f54bedb@haskell.org> References: <045.1cd550b891f74e462b3401513f54bedb@haskell.org> Message-ID: <060.4f0084a292235bd77112998df591db8f@haskell.org> #13335: Non-abstract types also have skolem nature -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"9603de6ac7a75ea7c620ce05e3c5f500bcaf5dd6/ghc" 9603de6a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9603de6ac7a75ea7c620ce05e3c5f500bcaf5dd6" Treat all TyCon with hole names as skolem abstract. Summary: Fixes #13335. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: goldfire, austin, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3211 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 00:03:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 00:03:37 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.2236ce24b302bc8f28ded8a424086da2@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"923d7ca2d90c1cb9816d14768abdd2e46adcd5dd/ghc" 923d7ca2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="923d7ca2d90c1cb9816d14768abdd2e46adcd5dd" Subtyping for roles in signatures. Summary: This commit implements the plan in #13140: * Today, roles in signature files default to representational. Let's change the default to nominal, as this is the most flexible implementation side. If a client of the signature needs to coerce with a type, the signature can be adjusted to have more stringent requirements. * If a parameter is declared as nominal in a signature, it can be implemented by a data type which is actually representational. * When merging abstract data declarations, we take the smallest role for every parameter. The roles are considered fix once we specify the structure of an ADT. * Critically, abstract types are NOT injective, so we aren't allowed to make inferences like "if T a ~R T b, then a ~N b" based on the nominal role of a parameter in an abstract type (this would be unsound if the parameter ended up being phantom.) This restriction is similar to the restriction we have on newtypes. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, austin, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D3123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 02:21:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 02:21:47 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.667f29aaf1433bea5f8d9ef36079b837@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 akio): * cc: akio (added) Comment: I'm sorry that my patch slowed down GHC by so much. I'll try to investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 02:49:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 02:49:11 -0000 Subject: [GHC] #13346: Run nofib with -fspec-constr-keen Message-ID: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> #13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Per Ben Gamari's comment on https://phabricator.haskell.org/D3186, we should try running `nofib` with `-fspec-constr-keen`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 03:47:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 03:47:28 -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.be840cba6bf48657905bb5546d4733b6@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.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): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 03:49:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 03:49:54 -0000 Subject: [GHC] #13347: Abstract classes in hs-boot should not be treated as injective Message-ID: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> #13347: Abstract classes in hs-boot should not be treated as injective -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- They could be implemented by a newtype (see `mkClass`), making them non- injective. Fortunately, this doesn't seem to cause any unsoundness, because the *constructor* for the newtype corresponding to a class is never in scope, so we are never allowed to unwrap "class newtypes". Phew! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 04:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 04:33:23 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.43bc349e553f97850b609272de53b1f9@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): I had a quick look. I am seeing significant increases in compiler allocations as early as typecheck/rename. For instance, in the case of `T5837` I see, ||= Phase =||= Before patch (megabytes) =||= After patch (megabytes) =|| || Parser || 1.069 || 1.069 || || Renamer/typechecker || 117.168 || 125.031 || || Desugar || 4.127 || 4.155 || || Simplifier || 0.746 || 0.811 || || CoreTidy || 2.277 || 2.516 || || CorePrep || 0.287 || 0.299 || || CodeGen || 6.804 || 6.845 || The only difference in the simplified core is due to the strings associated with the Typeable bindings. Before the patch we had, {{{#!hs $trModule4 :: GHC.Types.TrName $trModule4 = GHC.Types.TrNameS "T5837"# }}} Now we have, {{{#!hs $trModule3 :: GHC.Prim.Addr# $trModule3 = "T5837"# $trModule4 :: GHC.Types.TrName $trModule4 = GHC.Types.TrNameS $trModule3 }}} While some small fraction of the allocations change after CodePrep is attributable to the fact that StgSyn got slightly larger (since we now have a separate type for top-level bindings), this doesn't explain the difference during renaming/typechecking. I wonder if some of these newly floating string literals have snuck into interface files? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 04:40:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 04:40:54 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.e9c86a7c2d5a2fea969980b10cd1d861@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): Hmm, it seems that even `tc-trace` and `rn-trace` output is unchanged by the patch. It looks like I'll need to build some ticky'd compilers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 05:44:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 05:44:28 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.75103c063acb39babcb4b10909e97559@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): > There are two changes in that commit: Actually the only change is the latter one. The former change is already in HEAD, as of 2be364ac8c. > Making data con wrapper have ug_boring_ok = boringCxtOk. I'm not sure I buy this in full. In Note [Inline data constructor wrappers aggresively] there's a claim that we get better nested-CPR info. I don't think the improvement has anything to do with nested CPR, because I'm testing this change in isolation, without any other changes from the nested CPR branch. The big difference in nofib comes from the `GHC.Integer.Types` module in `integer-gmp`. This module has this definition: {{{#!hs data Integer = S# !Int# -- ^ iff value in @[minBound::'Int', maxBound::'Int']@ range | Jp# {-# UNPACK #-} !BigNat -- ^ iff value in @]maxBound::'Int', +inf[@ range | Jn# {-# UNPACK #-} !BigNat -- ^ iff value in @]-inf, minBound::'Int'[@ range }}} Note the redundant bang in the `S#` constructor. This causes a wrapper for this constructor to be created: {{{#!hs GHC.Integer.Type.$WS# = \ (dt [Occ=Once] :: Int#) -> case dt of dt { __DEFAULT -> GHC.Integer.Type.S# dt } }}} And this wrapper remains un-inlined in various places like: {{{#!hs quotRemInteger = \ (n :: Integer) (ds :: Integer) -> join { fail1 [Dmd=] :: Void# -> (# Integer, Integer #) [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] fail1 _ [Occ=Dead, OS=OneShot] = case n of n1 { __DEFAULT -> join { fail2 [Dmd=] :: Void# -> (# Integer, Integer #) [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] fail2 _ [Occ=Dead, OS=OneShot] = case n1 of wild { S# ds3 -> case ds3 of ds4 { __DEFAULT -> case ds of { S# d# -> case quotRemInt# ds4 d# of { (# ipv, ipv1 #) -> (# GHC.Integer.Type.$WS# ipv, GHC.Integer.Type.$WS# ipv1 #) ... }}} leading to unnecessary allocation of thunks. It should be possible to fix this problem by doing one of the following: 1. Inline constructor wrappers like `$WS#` aggressively, at least when it's fully applied. 2. Do not create a redundant wrapper in a case like this. 3. Remove this particular bang from integer-gmp. I have tried (1) and (3), and they seem to have very similar effects. (3) is definitely the easiest to implement, but I wonder if (2) is more correct. I'd like to hear some suggestions about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 08:30:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 08:30:50 -0000 Subject: [GHC] #13336: Improve or remove the glomming warning In-Reply-To: <049.d59b9b11467efecc0744316f457902ac@haskell.org> References: <049.d59b9b11467efecc0744316f457902ac@haskell.org> Message-ID: <064.be1cc5bf0dab618dc6687bfda11f29e5@haskell.org> #13336: Improve or remove the glomming warning -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > GHC dutifully warns us about this event but I can't work out why it this is necessary The actionable bit (not yet actioned!) is to examine cases where glomming happens a lot, and check that it is actually necessary. They may all be legit, but I know from experience that I make mistakes; perhaps there is an easy win lurking here. > What is bad about glomming? Two small things: first, the program is optimised without all the relevant bindings visible; second, we build a giant Rec and re-analyse it, which can't be cheap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 08:48:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 08:48:40 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.fe4d02ea0f29ec8b45baf4841ad83e8a@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13338 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You are very fast! I tripped across exactly this last week and have a patch in validation. Stay tuned. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 08:48:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 08:48:47 -0000 Subject: [GHC] #13345: GHC 8 type checker regression In-Reply-To: <051.bb48563af475a457fe8c108680ecf0a9@haskell.org> References: <051.bb48563af475a457fe8c108680ecf0a9@haskell.org> Message-ID: <066.0c548abe7cd1b6c62b6dfe3cc046f49f@haskell.org> #13345: GHC 8 type checker regression -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: type Resolution: invalid | annotation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andreas.abel): Well, I also tried {{{#!hs import qualified Data.List as List }}} and then use `List.foldl`, but it did not help. If this is "just a library design choice", maybe something went wrong there, but `base` is an integral part of `ghc`, thus, it is still a regression in that respect. What does work is to use `FunctionalDependencies` for the `Tr` class. But since this feature is still underdeveloped, not knowing about injectivity of type constructors, I also have to turn on the sledgehammer `UndecidableInstances`. If not a bug, at least the situation is unpleasant. There is no nice workaround. Except breaking up the code to smaller pieces and insert type annotations. (The original code was monadic, like:) {{{#!hs List.fold App Var <$> tr es }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 08:54:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 08:54:44 -0000 Subject: [GHC] #13339: Arbitrarily large expressions built out of cheap primops are not floated out In-Reply-To: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> References: <047.9343dfed954c72d8083ca35f5b895acc@haskell.org> Message-ID: <062.31c0b4e7ea6fdd7b47c7969387135cee@haskell.org> #13339: Arbitrarily large expressions built out of cheap primops are not floated out -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 simonpj): Yes, taking the size into account would be good. Floating this this out requires boxing it, and doing an eval/unbox inside the loop. When is that cheaper than a dozen in-register additions? I'm not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 10:02:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 10:02:12 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.c38a6bd9ab301575fdada0b05b603146@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 simonpj): > It looks like I'll need to build some ticky'd compilers. Indeed; thank you. This is deeply weird. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 10:05:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 10:05:42 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.d97e5e6199425f5b0ee102ea103652b3@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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 have no idea why the unfoldings for f and g would ever be stable It's done by `certainlyWillInline`. See `Note [Don't w/w inline small non-loop-breaker things]` in `WorkWrap`. I'd be happy to have a better way, but this is not terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 11:56:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 11:56:33 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.6bef0f4edd29ef01a8529bbca9a569b6@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13338 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah you'd made more progress than I thought. I've commented on Phab:D3217. Over to you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 13:49:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 13:49:25 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.dca792b89a9c201c69ccfe1b6523d045@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): Hmm, indeed ticky suggests that there is some leakage into interface files, {{{ | Change | alloc A | alloc B | name | |-----------|---------|---------|-------------------------------------------------------------------------------------------------| | +417944.0 | 3978840 | 4396784 | containers-0.5.7.1:Data.IntMap.Base.$winsert (:) | | +249216.0 | 1225560 | 1474776 | $wgo (ghc:BinIface) | | +166144.0 | 821968 | 988112 | go7 (ghc:LoadIface) | | +131256.0 | 1767520 | 1898776 | ghc:Module.$sinsertWith_$s$sgo10 (:) | | +75680.0 | 566080 | 641760 | mk_supply (ghc:UniqSupply) | | +68208.0 | 454152 | 522360 | unsafeDupableInterleaveIO1 (base:GHC.IO.Unsafe) | | +62016.0 | 1209552 | 1271568 | containers-0.5.7.1:Data.Map.Base.balanceL (:) | | +52864.0 | 1592272 | 1645136 | ghc:IfaceType.$w$cget6 (:) | | +45312.0 | 744224 | 789536 | ghc:Binary.$w$cget3 (:) | | +45312.0 | 226728 | 272040 | ghc:IfaceSyn.$w$cget1 (:) | | +45312.0 | 238080 | 283392 | ghc:TcRnMonad.$wforkM_maybe (:) | | +44776.0 | 934504 | 979280 | ghc:FastString.$wmkFastStringWith (:) | | +31360.0 | 340240 | 371600 | go (base:Data.OldList) | | +30208.0 | 156096 | 186304 | ghc:Module.$WDefiniteUnitId (:) | | +30208.0 | 156096 | 186304 | ghc:Module.$w$cget2 (:) | | +29008.0 | 1155896 | 1184904 | base:GHC.Base.++ (:) | | +27976.0 | 39000 | 66976 | ghc:TysWiredIn.$wisBuiltInOcc_maybe (:) | | +26432.0 | 130984 | 157416 | $wlvl12 (ghc:HscTypes) | | +26432.0 | 202496 | 228928 | bytestring-0.10.8.1:Data.ByteString.$wcopy (:) | | +26432.0 | 355440 | 381872 | ghc:NameCache.extendNameCache1 (:) | | +22768.0 | 71896 | 94664 | lexToken (ghc:Lexer) | | +22656.0 | 137472 | 160128 | ghc:Binary.$w$cget1 (:) | | +22656.0 | 107040 | 129696 | ghc:Binary.$wlazyGet (:) | | +22656.0 | 333696 | 356352 | ghc:FastString.$wmkFastStringByteString (:) | | +20544.0 | 0 | 20544 | ghc:TcRnMonad.emitInsoluble3 (:) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 13:59:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 13:59:34 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.df2e7c7765a140705d9262c0d9406e6b@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): Ahh, indeed I should have looked at the interface files sooner. There are indeed more bindings here. e.g., previously in `Prelude` we had (in `--show-iface` output), {{{#!hs $trModule :: Module {- HasNoCafRefs, Strictness: m, Unfolding: (Module $trModule2 $trModule1) -} }}} Now we have, {{{#!hs $trModule1 :: TrName {- HasNoCafRefs, Strictness: m1, Unfolding: (TrNameS $trModule2) -} $trModule2 :: Addr# {- HasNoCafRefs, Unfolding: ("Prelude"#) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 14:41:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 14:41:32 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.d2ef7382669227565d69711faa867487@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 bgamari): Just looking at the interface file sizes between the two trees, it appears that many files increased by a few hundred bytes with a few (e.g. `GHC.Show`, `GHC.Generics`) increasing by some kilobytes. For future reference I performed the comparison with, {{{#!sh echo "delta after before file" paste \ <(ls -l $(find ghc-compare-1/libraries/base/dist-install -iname *.hi) | awk '{print $5,$9}') \ <(ls -l $(find ghc-compare-2/libraries/base/dist-install -iname *.hi) | awk '{print $5,$9}') \ | awk '{ print (($1 - $3)), $1, $3, $2}' | sort -rn | less }}} Which results in {{{ 16461 800034 783573 libraries/base/dist-install/build/GHC/Generics.hi 7673 130677 123004 libraries/base/dist-install/build/GHC/RTS/Flags.hi 7555 969695 962140 libraries/base/dist-install/build/Data/Data.hi 7449 103629 96180 libraries/base/dist-install/build/GHC/IO/Exception.hi 7068 268944 261876 libraries/base/dist-install/build/Data/Foldable.hi 6904 136200 129296 libraries/base/dist-install/build/GHC/Show.hi 4830 211720 206890 libraries/base/dist-install/build/Data/Monoid.hi 4767 458028 453261 libraries/base/dist-install/build/Data/Semigroup.hi 4735 498885 494150 libraries/base/dist-install/build/Foreign/C/Types.hi 4651 59316 54665 libraries/base/dist-install/build/GHC/IO/Handle/Types.hi ... }}} In the case of `GHC.Generics` we now have things like, {{{#!hs $fEqV14 :: [Char] {- Unfolding: (unpackCString# $fEqV15) -} $fEqV15 :: Addr# {- HasNoCafRefs, Unfolding: ("error"#) -} }}} Whereas we previously had, {{{#!hs $fEqV11 :: [Char] {- Unfolding: (unpackCString# "error"#) -} }}} One potential improvement we can make here (at the expense of some constant folding opportunities) is to drop the unfoldings from `Addr#` bindings; afterall, in most cases there is little benefit to inlining the string literal. In the case of the `Typeable` bindings, I'm very tempted to just eliminate unfoldings from all generated `TrName`s. This would likely cut down on interface file sizes dramatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 16:24:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 16:24:42 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.8092daf003ddd3a13403b72524de6c73@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: Rwbarton, I looked at the question from all side and you are right. The clock cycles of an instruction do not varies but the number of clock cycles to go from the registers to memory or cache memory can be different. So it is impossible to have an absolute time (CPU time) but only a relative time of CPU in current processors. Sorry!. I closed this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 17:49:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 17:49:51 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.9d1df9358e748ca0b18f800fb677b71b@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 gridaphobe): * cc: gridaphobe (added) Comment: Replying to [comment:3 bgamari]: > I asked David look into this a few weeks back; he says that he may have seen duplicated strings in Core. > > `T5837` looks like it would be a good testcase to evaluate this issue with. FWIW, I noticed this weekend that Phab:D2605 did not enable CSE on the floated literals. I think the latest 1% decrease in binary sizes in my Phab:D1259 is largely due to enabling CSE on the floated strings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 17:54:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 17:54:05 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous In-Reply-To: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> References: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> Message-ID: <061.ddc88177139e6dc36a99201f1f036eb5@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | 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 Feb 27 17:56:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 17:56:11 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.a0aa9176d151fa1bf8fd2ae0eecf6faa@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 gridaphobe): Actually, I retract my comment, I think I grossly misunderstood what the `exprIsLiteralString` check in `tryForCSE` was doing.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 19:14:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 19:14:08 -0000 Subject: [GHC] #13249: Default signature check can be quite onerous In-Reply-To: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> References: <046.e143571ec70554b4405bcd5475c729b7@haskell.org> Message-ID: <061.d6e71c92f5025a62b3f8989e324926dd@haskell.org> #13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sorry for not noticing this sooner, but I agree with Simon that the situation is not as dire as it seems. It should be noted that the correct default type signature could actually be made a little shorter: {{{#!hs default remaining :: (MonadTrans t, MonadGet n, m ~ t n, Remaining m ~ Remaining n) => m (Remaining m) }}} That is, the `MonadGet n` constraint implies the `Monad n` constraint. I don't think four constraints is a unreasonable amount to ask for, given that we're using the "lift something into a `MonadTrans`" design pattern, which requires repeating the constraints (and associated type families) for the type that is lifted anyway. Also, to answer Iceland_jack's question: no, `t m (Remaining m)` would not be valid, both in the sense that GHC will reject it and in a semantic sense, as you're conflating two different `Monad`s. The first `m` in `t m (Remaining m)` represents the `Monad` you're lifted, while the second `m` is for the type which is a `MonadTrans` (i.e, the thing you're lifting into). Failing to distinguish between these two things has led to all sorts of problems in the past (see #12784), which is one the reasons we introduced this check in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 19:43:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 19:43:13 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.97f40187be784145f370f890b874cf59@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.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 rwbarton): The patch in #8472 allows floating out unboxed string literals to top level in (at least) three places: 1. In the "Floats" section in SimplEnv we float a let out of a let. If the body of the let is a lambda then we can increase the arity of the original binding, which is a good thing. This is the optimization that was allowed in the example of #8472 by letting the unboxed string literal float to the top level. 2. In `prepareRhs` in Simplify we can float, for example, an argument out of a constructor. In general this brings us closer to ANF, but when the argument is a literal it is trivial already; and the data representation we generate for `Ptr "blob"#` is just fine. 3. In the float out pass we can float out an expression to avoid repeated allocation or evaluation. But there is no allocation or evaluation associated to an unboxed literal. In https://github.com/ghc/ghc/commit/8f99cfa49be0fc0767f0c73967ff2472de5cfcd6 I've tried disabling the above items 2 and 3 for unboxed string literals. It still produces the desired code in the example of #8472, but it no longer floats the string literals out of, for example, `$trModule` bindings. I'm waiting to see what perf.haskell.org thinks about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 20:33:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 20:33:30 -0000 Subject: [GHC] #13348: Consider making throw and throwIO strict Message-ID: <045.a5abd3b4410092f9c7aec0b840de925c@haskell.org> #13348: Consider making throw and throwIO strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's possible for code to throw an exception that itself throws an imprecise exception. Such an exception is tricky to catch. For example: {{{#!hs import Control.Exception strange = throwIO (undefined :: SomeException) `catch` \ex -> case () of _ | Just _ <- (fromException ex :: Maybe IOError) -> print "IOError" | otherwise -> print "Something else" }}} You might think that this would catch the exception and print "Something else", but in fact it does not. If others think this is as surprising as I do, perhaps we should make `throwIO` and `throw` strict, so an exception will never itself be bottom. Using {{{#!hs throwIO' !e = throwIO e }}} in the code above instead of `throwIO` allows the exception to be caught. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 27 21:31:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Feb 2017 21:31:51 -0000 Subject: [GHC] #10833: Use injective type families (decomposition) when dealing with givens (was: Use injective type families when dealing with givens) In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.410cbd253bcf53e2aa738342425e955c@haskell.org> #10833: Use injective type families (decomposition) when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018, #11511, | Differential Rev(s): #12199 | Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 02:02:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 02:02:19 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.347d06b81ac370a8c417d9137d44adab@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elliottt): The problem seems to be that the quoted expression {{{[|| _x ||]}}} will introduce a hole constraint of the form {{{ _x :: a }}} when spliced, but that the error will be reported outside of the implication introduced by the signature. When checking the following program: {{{ m :: a m = _x }}} {{{simplifyTop}}} will report that it's found an unsolved wanted constraint of the form {{{ forall (a :: *). () => _x :: a }}}. However, when checking the original program, {{{simplifyTop}}} is called from a different path ({{{tcTopSpliceExpr}}}), and reports the wanted constraint as being of the form {{{ _x :: a }}}. As it lacks the context of the binding for {{{a}}}, it falls through to the base case of {{{getSkolemInfo}}}, which causes the panic. At this point, I'm not sure what the right path forward is. Should {{{tcTopSpliceExpr}}} be using {{{simplifyTop}}}, or is there just some additional context needed to be setup before that call? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 08:20:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 08:20:33 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.7f7bfbe2163135cf169f0031478253e7@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Here's another way to think about app-roles and proj-roles. Previously, we thought of roles as a single thing you ascribe to a type parameter. But it would be more accurate to say that a type parameter is given a role ''range'', which specifies the possible set of underlying roles that the type may be implemented with. For example, the range "phantom to nominal" says that the type could be implemented in a way that treats the type variable phantom, representationally, or nominally: this is the most flexible for the implementor and gives the least information to the client. Or you can say that it is "exactly" nominal: this gives the most information to the client. `type role T nominal; newtype T a = MkT a` gets "representational to nominal": the annotation sets the upper bound, but the lower bound has to actually include the true role which a is used at. Of course, when I say lower bound, I mean proj-role, and when I say upper- bound, I mean app role. (I also apologize for flipping the subroling order.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 12:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 12:38:05 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.5b3b161f822a12c011788fd60b67dc86@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In a conversation on Monday I think we agreed: * We should try changing `catch#` to be lazy (but still with a `C1(d)` usage) and see what perf effect, if any, that has. * Neil Mitchell was part of the conversation on #11555; see comment:11 there. So let's check with him too. I think David is leading on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 12:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 12:54:16 -0000 Subject: [GHC] #13294: compactResize is a terrible primop and a terrible name In-Reply-To: <045.dae6d915b6b6656cda9997bbc39b708a@haskell.org> References: <045.dae6d915b6b6656cda9997bbc39b708a@haskell.org> Message-ID: <060.24a1d8a08f66f7ad85a1555220483d3f@haskell.org> #13294: compactResize is a terrible primop and a terrible name -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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): Yes, I completely agree. I didn't look at this operation much during my recent overhaul, and I'm not using it. I don't remember why I moved it. Feel free to make it better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 12:56:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 12:56:03 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.8d9b38e9484de99b1a1e39ebe133fa91@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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 realised the following two things. * If we wanted to distinguish between stable-unfoldings created by user- specified INLINE pragmas, from those created by `WorkWrap` (see `Note [Don't w/w inline small non-loop-breaker things] there), we can do so. The former has `inl_spec = Inline` in its `InlinePragma`; the latter has `inl_spec = EmptyInlineSpec`. * But re-reading the note {{{ Note [CSE for stable unfoldings] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider {-# Unf = Stable (\pq. build blah) #-} foo = x Here 'foo' has a stable unfolding, but its (optimised) RHS is trivial. (Turns out that this actually happens for the enumFromTo method of the Integer instance of Enum in GHC.Enum.) Then we obviously do NOT want to extend the substitution with (foo->x)! See similar SimplUtils Note [Stable unfoldings and postInlineUnconditionally]. Nor do we want to change the reverse mapping. Suppose we have {-# Unf = Stable (\pq. build blah) #-} foo = bar = There could conceivably be merit in rewriting the RHS of bar: bar = foo but now bar's inlining behaviour will change, and importing modules might see that. So it seems dodgy and we don't do it. }}} suppose both `foo` and `bar` have a stable-unfolding, and they are identical. That's exactly the situation in the examples above. Then it'd be fine to replace `bar` by `foo`. I think we should try the second of these. Not hard I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 14:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 14:52:17 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.e35aa000af4f10fefab0cb98fba4be3f@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm working on that this morning. The plan is pretty much as you indicated. I'm building now and will try out the benchmarks when it's done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 15:59:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 15:59:06 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.14324645da2e9f3ca11df6fdedd205e5@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T13338 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d0508ef001e9c93920f6eb066cab5e79041cb886/ghc" d0508ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d0508ef001e9c93920f6eb066cab5e79041cb886" When floating, don't box an expression that's okay for speculation (#13338) Commit 432f952e (Float unboxed expressions by boxing) lets the float-out pass turn, for example, ... (-# (remInt# x# 100000#) i#) ... into let lvl :: Int lvl = case remInt# x# 100000# of v { __DEFAULT__ -> I# v } in ... (-# (case lvl of { I# v -> v }) i#) ... But when, as in the example above, the expression that was floated out was the argument of an application, the resulting application may no longer satisfy the let/app invariant, because exprOkForSpeculation doesn't look far enough inside the definition of lvl. Solution: When the expression we floated out was okay for speculation, don't bother boxing it. It will be evaluated earlier, and that's okay by assumption. Fixes the let/app invariant and is cheaper too. Test Plan: make slowtest TEST=T13338 Reviewers: austin, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3217 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:06:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:06:48 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better Message-ID: <050.1ed46c9c098322461a08260277adee24@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Like orphan rewrite rules, it's possible to define orphan `COMPLETE` sets. For instance: {{{#!hs module Foo where {-# COMPLETE False #-} }}} I suppose that we could define an orphan `COMPLETE` set as one that lives in a module where none of the conlikes are defined (or should we say "where one or more of the conlikes are not defined"? I'm not sure.) Like orphan `RULES`, orphan `COMPLETE` sets are important to track properly when transitively reading from interface files, as failing to bring an orphan `COMPLETE` set into scope could affect pattern-match exhaustivness warnings that users see. After discussing this with rwbarton and mpickering IRC, we decided that one of the two should happen: 1. Treat orphan `COMPLETE` sets like orphan `RULES`. That is, mark a module as an orphan if it defines an orphan `COMPLETE` set, and thread a "`COMPLETE` pragma visibility" state through various places. 2. Disallow orphan `COMPLETE` sets entirely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:16:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:16:08 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.3177c5b307b19cf2909c349008343149@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => highest * milestone: => 8.2.1 Comment: Let's do 2 before COMPLETE pragmas are released into the wild, so that nobody starts to depend on orphan COMPLETE pragmas. I assume it is not difficult. Then we could consider whether to do 1 later; but that is certainly a fair amount of work and probably not worthwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:29:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:29:55 -0000 Subject: [GHC] #13203: Implement Bits Natural clearBit In-Reply-To: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> References: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> Message-ID: <059.c82632616e6b9d062a09d8119ab58835@haskell.org> #13203: Implement Bits Natural clearBit -------------------------------------+------------------------------------- Reporter: dylex | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vlopez): At least it should be documented that `clearBit` is undefined. For implementing `clearBit`, instead of doing a conditional `complementBit` on `testBit`, I suggest doing a `complementBit` after `setBit`. This avoids branching entirely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:35:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:35:32 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages Message-ID: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you define these two modules: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo where data KindRep = KindRepTyConApp | KindRepVar | KindRepApp | KindRepFun | KindRepTYPE | KindRepTypeLitS | KindRepTypeLitD pattern KindRepTypeLit :: KindRep pattern KindRepTypeLit = KindRepTypeLitD {-# COMPLETE KindRepTyConApp, KindRepVar, KindRepApp, KindRepFun, KindRepTYPE, KindRepTypeLit #-} }}} {{{#!hs module Bar where import Foo krInt :: KindRep -> Int krInt KindRepTyConApp{} = 0 krInt KindRepVar{} = 1 krInt KindRepApp{} = 2 krInt KindRepFun{} = 3 krInt KindRepTYPE{} = 4 krInt KindRepTypeLit{} = 5 }}} And you compile `Bar.hs` with `-Wall` on, it will not emit any pattern- match exhaustiveness warnings, as expected. However, something different happens if you import all of these `KindRep` conlikes from `Type.Reflection.Unsafe` instead: {{{#!hs module Bar where import Type.Reflection.Unsafe krInt :: KindRep -> Int krInt KindRepTyConApp{} = 0 krInt KindRepVar{} = 1 krInt KindRepApp{} = 2 krInt KindRepFun{} = 3 krInt KindRepTYPE{} = 4 krInt KindRepTypeLit{} = 5 }}} {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -Wall Bar.hs GHCi, version 8.1.20170228: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bar ( Bar.hs, interpreted ) Bar.hs:6:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘krInt’: Patterns not matched: (KindRepTypeLitS _ _) (KindRepTypeLitD _ _) | 6 | krInt KindRepTyConApp{} = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} When the `COMPLETE` set is defined in a module in an //external package// (`base:Type.Reflection.Unsafe`, in this example), GHC doesn't properly take it into account when emitting pattern-match exhaustiveness warnings! This makes `COMPLETE` sets not terribly useful in practice at the moment. (NB: `Type.Reflection.Unsafe`'s definitions of `KindRepTyConApp` //et al.// aren't quite the same as what I defined above, but their exact definitions aren't important here, just that they have the same names and `COMPLETE` set. And this is the only `COMPLETE` set that I could defined in the boot libraries at the moment, making it convenient to use.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:44:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:44:11 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.733389c5bea83df0943f21a6a1305580@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => highest * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:44:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:44:32 -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.7ffa30a594fc4d7a06f66cfaf1b73314@haskell.org> #11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > 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). New description: Tools like [[https://github.com/DanielG/ghc-mod/|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 Tue Feb 28 16:50:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:50:31 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.1620ec58d2585c605b8b95d50418a4a5@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: (none) => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 16:53:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 16:53:30 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.00c452801d281ed4ab9ed75442b0919e@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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 mpickering): I think there is just one place to change in the renamer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 17:02:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 17:02:34 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.c4d21188bd908cdbe1b2dc882276e36c@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, 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 simonpj): Using homogeneous coercions means that `KindCo` is gone; and that in turn perhaps means that the difficulties with using ''representational'' casts in types might go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 17:13:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 17:13:32 -0000 Subject: [GHC] Trac email verification for user: anubhav94 Message-ID: <20170228171332.4511C3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: anubhav94 Verification Token: 2l51Pn90 -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 17:50:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 17:50:01 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.120e77cd04d5dc1cca3b368c74e488d4@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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): Phab:D3243 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * differential: => Phab:D3243 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 17:58:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 17:58:59 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.03b62934d59ef8aa261c841e8e177ff0@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: (none) => RyanGlScott -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 19:28:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 19:28:20 -0000 Subject: [GHC] #13351: Investigate a foldr rule for short static lists Message-ID: <046.13d899ed45a956df7d11fe286d18173d@haskell.org> #13351: Investigate a foldr rule for short static lists -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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: -------------------------------------+------------------------------------- GHC.Base says: {{{ -- The foldr/cons rule looks nice, but it can give disastrously -- bloated code when commpiling -- array (a,b) [(1,2), (2,2), (3,2), ...very long list... ] -- i.e. when there are very very long literal lists -- So I've disabled it for now. We could have special cases -- for short lists, I suppose. -- "foldr/cons" forall k z x xs. foldr k z (x:xs) = k x (foldr k z xs) "foldr/single" forall k z x. foldr k z [x] = k x z "foldr/nil" forall k z. foldr k z [] = z }}} I wonder if we should extend the list of rules at the bottom to a few more list lengths, as the comment suggests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 19:45:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 19:45:18 -0000 Subject: [GHC] #13348: Consider making throw and throwIO strict In-Reply-To: <045.a5abd3b4410092f9c7aec0b840de925c@haskell.org> References: <045.a5abd3b4410092f9c7aec0b840de925c@haskell.org> Message-ID: <060.84bd049844276646c423ec62a37ec1e6@haskell.org> #13348: Consider making throw and throwIO strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: wontfix | 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 dfeuer): * status: new => closed * resolution: => wontfix Comment: Eric Mertens has given a reasonable argument against this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 19:50:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 19:50:17 -0000 Subject: [GHC] #13352: Strange requirement for re-exported duplicate record fields Message-ID: <047.ff8942cd67c302be28d2cd71e3d50d5d@haskell.org> #13352: Strange requirement for re-exported duplicate record fields -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, {{{ module A(A(..)) where data A = A {x::Int} module B(B(..)) where data B = B {x::Bool} {-# LANGUAGE DuplicateRecordFields #-} module C(A(..),B(..)) where import A(A(..)) import B(B(..)) }}} I get an error about `conflicting exports for 'x'`. This doesn't seem right to me: I've got `-XDuplicateRecordFields` exactly where the duplicate occurs. However, I noticed that the if I move the pragma to A.hs, C.hs compiles without error: {{{ {-# LANGUAGE DuplicateRecordFields #-} module A(A(..)) where data A = A {x::Int} module B(B(..)) where data B = B {x::Bool} module C(A(..),B(..)) where import A(A(..)) import B(B(..)) }}} This is bizarre because it is asymmetric (I arbitrarily put the pragma in A.hs, but it need not occur in B.hs), and because no duplicate records exist in module A, but they ''do'' exist in module C, where the pragma isn't needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 19:51:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 19:51:54 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently Message-ID: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- I just had a project where it made a difference whether I add {{{ {-# RULES "foldr/nil" forall k n . GHC.Base.foldr k n [] = n #-} }}} to my file or not, despite this rule already being present in the library. I tried to minimize the problem and came up with this: {{{#!hs foo1 (f, fs) (x, xs) = (f x, map ($x) fs ++ map f xs) foo2 f fs x xs = (f x, map ($x) fs ++ map f xs) test1 x xs = foo1 (id, []) (x, xs) test2 x xs = foo2 id [] x xs test3 x xs = (id x, map ($x) [] ++ map id xs) }}} `test2` and `test3` nicely optimize the `map … [] ++` away, but `test` does not. (In this minimized example, adding the rule again locally does *not* help, but there is still something fishy.) Also, in all cases, `map id` remains, which should not be the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 19:54:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 19:54:45 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently In-Reply-To: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> References: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> Message-ID: <061.a3ea575529a00e0911d6f70f36a05693@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): Hmm, maybe I minimized the problem too much. If I do not export `foo1`, things work fine. Sigh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 20:13:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 20:13:53 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently In-Reply-To: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> References: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> Message-ID: <061.8ade7ae6f2e72f08ab3cc5ec35f782ee@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): Ok, so here is the deal. I get this core in the end: {{{ test1 test1 = \ @ a_aYA x_s1dJ xs_s1dK -> let { sat_s1dT sat_s1dT = let { z_s1dL z_s1dL = map id xs_s1dK } in letrec { go_s1dM go_s1dM = \ ds_s1dN -> case ds_s1dN of { [] -> z_s1dL; : y_s1dP ys_s1dQ -> let { sat_s1dS sat_s1dS = go_s1dM ys_s1dQ } in let { sat_s1dR sat_s1dR = y_s1dP x_s1dJ } in : sat_s1dR sat_s1dS }; } in go_s1dM [] } in (x_s1dJ, sat_s1dT) }}} Note the useless application of what used to be `foldr` to `[]`. Also note that `foo1` was obviously inlined. If I explicitly `INLINE foo1`, then I get: {{{ test1 test1 = \ @ a_aYA x_s1dh xs_s1di -> let { sat_s1dj sat_s1dj = map id xs_s1di } in (x_s1dh, sat_s1dj) }}} So despite GHC deciding to inline `foo1` (eventually), making it inline it early makes a big difference. With the `INLINE` pragma, GHC first considers to inline `foo1` in simplifier phase 2, after float out. {{{ Considering inlining: foo1 arg infos [ValueArg, ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance ALWAYS_IF(arity=2,unsat_ok=False,boring_ok=False) ANSWER = YES }}} Without we make a difference decision at this point: {{{ Considering inlining: foo1 arg infos [ValueArg, ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [20 20] 240 30 discounted size = 150 ANSWER = NO }}} but later, when foo1 has been w/w’ed, we inline it (i.e. the wrapper) in the post-w/w simplifer phase 0. {{{ Considering inlining: foo1 arg infos [ValueArg, ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) ANSWER = YES Inlining done: foo1 Inlined fn: \ @ a @ a w_s12e w_s12f -> case w_s12e of { (ww_s12i, ww_s12j) -> case w_s12f of { (ww_s12n, ww_s12o) -> case $wfoo1 ww_s12i ww_s12j ww_s12n ww_s12o of { (# ww_s12u, ww_s12v #) -> (ww_s12u, ww_s12v) } } } Cont: ApplyToTy a ApplyToTy a ApplyToVal nodup lvl_s11y ApplyToVal nodup (x, xs) Stop[BoringCtxt] (a, [a]) }}} and shortly after, we inline the worker: {{{ Considering inlining: $wfoo1_s12t arg infos [ValueArg, ValueArg, TrivArg, TrivArg] interesting continuation CaseCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [60 0 0 0] 180 30 discounted size = -5 ANSWER = YES Inlining done: $wfoo1 Inlined fn: \ @ a @ a ww_s12i ww_s12j ww_s12n ww_s12o -> let { ww_s12v ww_s12v = let { z z = map ww_s12i ww_s12o } in letrec { go go = \ ds -> case ds of { [] -> z; : y ys -> : (y ww_s12n) (go ys) }; } in go ww_s12j } in (# ww_s12i ww_s12n, ww_s12v #) Cont: ApplyToTy a ApplyToTy a ApplyToVal nodup ww_s12i ApplyToVal nodup ww_s12j ApplyToVal nodup ww_s12n ApplyToVal nodup ww_s12o Select nodup ww_s12s Stop[BoringCtxt] (a, [a]) }}} So it seems that after splitting the function into two pieces, it is small enough(?) so that both pieces inline? But that seems to be suboptimal: If we are going to inline both pieces anyways, can we not do it earlier, and thus enable useful fusion? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 20:47:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 20:47:24 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.bae843fa76357990410667c568ea948b@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): It looks to me like the original work behind trying to be extra-clever about `catchException` demand analysis might be recoverable. Fundamentally, this has very little to do with `catch#` per se. The primop it suggests is a sort of `forceIO :: (State# s -> (# State# s, a)) -> (State# s -> (# State# s, a))`. The intuition behind this primop is that it reduces an `IO` action to something with precisely the form {{{#!hs \s -> case PRIMOP s of (# s', ... #) -> e }}} I don't know if this is actually implementable, but I think it's probably what all that fanciness in `Demand.hs` was trying to get at. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 20:50:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 20:50:35 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.86e600ea53ae4004984748f37177bacf@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"122c67763bd73144bc6f3a6d86f275e6d1e297f9/ghc" 122c6776/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="122c67763bd73144bc6f3a6d86f275e6d1e297f9" Add COMPLETE pragmas for TypeRep and ErrorCall pattern synonyms When programming with the pattern synonyms for `TypeRep`, I noticed that I was receiving spurious non-exhaustive pattern-match warnings. This can be easily fixed by adding `COMPLETE` pragmas for them. Moreover, there's another pattern synonym in `base`: `ErrorCall`. In fact, in the original ticket for `COMPLETE` pragmas (#8779), someone requested that `ErrorCall` be given a `COMPLETE` pragma as well (https://ghc.haskell.org/trac/ghc/ticket/8779#comment:21). I decided to do that as well while I was in town. Reviewers: bgamari, mpickering, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3231 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 20:50:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 20:50:53 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.0178f42736e26477c779cda8e0138eff@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Oh, I guess that's not quite right. It's trying to force everything that would be forced if the action runs to completion, isn't it? I have grave doubts about this being a useful and well-defined idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 20:55:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 20:55:16 -0000 Subject: [GHC] #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary In-Reply-To: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> References: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> Message-ID: <061.e6d57543711c7ffb09bb832960dae0b7@haskell.org> #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc3 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 Iceland_jack): I get a Googlelocatably-similar error message with {{{#!hs {-# LANGUAGE PolyKinds, TypeInType #-} import GHC.Exts data A :: TYPE rep -> Constraint }}} using GHC version 8.0.2 {{{ *** Exception: expectJust zonkTcTyVarToVar CallStack (from HasCallStack): error, called at compiler\utils\Maybes.hs:48:27 in ghc:Maybes }}} I can't remember if this has been reported already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 21:18:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 21:18:02 -0000 Subject: [GHC] #13352: Strange requirement for re-exported duplicate record fields In-Reply-To: <047.ff8942cd67c302be28d2cd71e3d50d5d@haskell.org> References: <047.ff8942cd67c302be28d2cd71e3d50d5d@haskell.org> Message-ID: <062.b1db0becc7b6e7f2d17cd4955e3db1c5@haskell.org> #13352: Strange requirement for re-exported duplicate record fields -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: adamagundry (added) Comment: CC'ing adamgundry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 28 21:42:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Feb 2017 21:42:50 -0000 Subject: [GHC] #13351: Investigate a foldr rule for short static lists In-Reply-To: <046.13d899ed45a956df7d11fe286d18173d@haskell.org> References: <046.13d899ed45a956df7d11fe286d18173d@haskell.org> Message-ID: <061.a56e2b4ad4e4e4ad948abbd8c456717a@haskell.org> #13351: Investigate a foldr rule for short static lists -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch 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): Phab:D3246 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3246 Comment: Patch for review at Phab:D3246 -- Ticket URL: GHC The Glasgow Haskell Compiler