From ghc-devs at haskell.org Sun Jan 1 00:10:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 00:10:50 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.91ac6bb9193ec1e4bd3c59d8f782c006@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12595 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #12595 Comment: Hmm, it was #12595, but it claims to have been fixed in 8.0 already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 00:54:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 00:54:29 -0000 Subject: [GHC] #13051: Make the Register Allocator Loop-Aware Message-ID: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> #13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D2903 | Wiki Page: -------------------------------------+------------------------------------- Currently the graph coloring register allocator has 2 spill cost functions: one that implements Chaitin’s spill cost function and one that just spills the longest live range. We currently use the latter. Neither of them have any knowledge of program structure’ the register allocator basically assumes all code runs an equal number of times and therefore it doesn’t matter where you insert spills. By making it aware of loops and biasing it to avoid spilling in them when possible loops can run significantly faster. Obviously we don’t actually write loops in Haskell but we definitely still have them underneath our abstractions. Since we don’t write them explicitly we have to find them in our output (which is what the bulk of LoopAnnotations.hs does). A loop is just a place where control flow doubles back on itself, so we walk through the jumps (we already know where these are because the output has been divided into basic blocks) and try to find places where that happens. Currently if we have virtual registers born before a loop that are used in a large number of instructions before and after the loop but not in it we’ll avoid spilling them because it looks like we’ll have to reload them right away. In reality we won’t use them until the end of the loop which might be an order of magnitude of clock cycles later. So we’ll spill something else inside the loop which means every time the loop runs we run spill code. The goal is to have more intelligently placed spills and reloads instead of simply minimizing the number of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 00:54:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 00:54:53 -0000 Subject: [GHC] #13051: Make the Register Allocator Loop-Aware In-Reply-To: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> References: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> Message-ID: <061.24784cc1670208333b6f619c1d84bfd1@haskell.org> #13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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): D2903 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * owner: => tjakway -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 00:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 00:55:17 -0000 Subject: [GHC] #13051: Make the Register Allocator Loop-Aware In-Reply-To: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> References: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> Message-ID: <061.d98329ca5795b66fd3e003bff044d5ed@haskell.org> #13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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:D2903 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * differential: D2903 => Phab:D2903 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 01:01:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 01:01:53 -0000 Subject: [GHC] #13051: Make the Register Allocator Loop-Aware In-Reply-To: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> References: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> Message-ID: <061.18abba9a3a2a12a7c57e3957e4c30f84@haskell.org> #13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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:D2903 Wiki Page: | -------------------------------------+------------------------------------- Description changed by tjakway: @@ -9,0 +9,7 @@ + Currently if we have virtual registers born before a loop that are used in + a large number of instructions before and after the loop but not in it + we’ll avoid spilling them because it looks like we’ll have to reload them + right away. In reality we won’t use them until the end of the loop which + might be an order of magnitude of clock cycles later. So we’ll spill + something else inside the loop which means every time the loop runs we run + spill code. @@ -18,8 +25,0 @@ - Currently if we have virtual registers born before a loop that are used in - a large number of instructions before and after the loop but not in it - we’ll avoid spilling them because it looks like we’ll have to reload them - right away. In reality we won’t use them until the end of the loop which - might be an order of magnitude of clock cycles later. So we’ll spill - something else inside the loop which means every time the loop runs we run - spill code. - New description: Currently the graph coloring register allocator has 2 spill cost functions: one that implements Chaitin’s spill cost function and one that just spills the longest live range. We currently use the latter. Neither of them have any knowledge of program structure’ the register allocator basically assumes all code runs an equal number of times and therefore it doesn’t matter where you insert spills. By making it aware of loops and biasing it to avoid spilling in them when possible loops can run significantly faster. Currently if we have virtual registers born before a loop that are used in a large number of instructions before and after the loop but not in it we’ll avoid spilling them because it looks like we’ll have to reload them right away. In reality we won’t use them until the end of the loop which might be an order of magnitude of clock cycles later. So we’ll spill something else inside the loop which means every time the loop runs we run spill code. Obviously we don’t actually write loops in Haskell but we definitely still have them underneath our abstractions. Since we don’t write them explicitly we have to find them in our output (which is what the bulk of LoopAnnotations.hs does). A loop is just a place where control flow doubles back on itself, so we walk through the jumps (we already know where these are because the output has been divided into basic blocks) and try to find places where that happens. The goal is to have more intelligently placed spills and reloads instead of simply minimizing the number of them. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 01:02:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 01:02:08 -0000 Subject: [GHC] #13051: Make the Register Allocator Loop-Aware In-Reply-To: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> References: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> Message-ID: <061.4d2244d2bbea034bcb2c14367b1473cf@haskell.org> #13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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:D2903 Wiki Page: | -------------------------------------+------------------------------------- Description changed by tjakway: @@ -9,0 +9,1 @@ + New description: Currently the graph coloring register allocator has 2 spill cost functions: one that implements Chaitin’s spill cost function and one that just spills the longest live range. We currently use the latter. Neither of them have any knowledge of program structure’ the register allocator basically assumes all code runs an equal number of times and therefore it doesn’t matter where you insert spills. By making it aware of loops and biasing it to avoid spilling in them when possible loops can run significantly faster. Currently if we have virtual registers born before a loop that are used in a large number of instructions before and after the loop but not in it we’ll avoid spilling them because it looks like we’ll have to reload them right away. In reality we won’t use them until the end of the loop which might be an order of magnitude of clock cycles later. So we’ll spill something else inside the loop which means every time the loop runs we run spill code. Obviously we don’t actually write loops in Haskell but we definitely still have them underneath our abstractions. Since we don’t write them explicitly we have to find them in our output (which is what the bulk of LoopAnnotations.hs does). A loop is just a place where control flow doubles back on itself, so we walk through the jumps (we already know where these are because the output has been divided into basic blocks) and try to find places where that happens. The goal is to have more intelligently placed spills and reloads instead of simply minimizing the number of them. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 06:17:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 06:17:59 -0000 Subject: [GHC] #13050: Holes don't work infix In-Reply-To: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> References: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> Message-ID: <066.40f9497d0fdaf1374cd5b5e59abf1c54@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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:D2910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D2910 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 16:15:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 16:15:39 -0000 Subject: [GHC] #13049: Make `-dead_strip` the default on Darwin In-Reply-To: <047.db5905269068938cc53fd620b92bef9f@haskell.org> References: <047.db5905269068938cc53fd620b92bef9f@haskell.org> Message-ID: <062.b0c1d8e02c5a5c8d90ce12828cec58f1@haskell.org> #13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | 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 olsner): Dead-code stripping on Mac probably also depends on #11040. Both split- objs and split-sections split SRT tables (and that did quite a bit to get rid of references to dead code), but IIRC the `-dead_strip` support is not doing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 16:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 16:47:17 -0000 Subject: [GHC] #13052: unsafePerformIO duped on multithread if within the same IO thunk Message-ID: <046.4be60181dd029c0c19970eaecfa55541@haskell.org> #13052: unsafePerformIO duped on multithread if within the same IO thunk -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 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): | Wiki Page: -------------------------------------+------------------------------------- Unlike `unsafeDupablePerformIO`, an `unsafePerformIO` block is not supposed to be executed more than once when two threads race to evaluate it, and yet the following program detects that the counter is sometimes incremented twice: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# OPTIONS -O0 -threaded -rtsopts -with-rtsopts=-N #-} module Main where import Control.Concurrent import System.IO.Unsafe runThreads :: IO () -> IO () -> IO () runThreads body1 body2 = do var1 <- newEmptyMVar var2 <- newEmptyMVar _ <- forkIO $ do { !_ <- body1; putMVar var1 () } _ <- forkIO $ do { !_ <- body2; putMVar var2 () } takeMVar var1 takeMVar var2 main :: IO () main = do counter <- newMVar (0 :: Int) let sharedThunk = unsafePerformIO $ modifyMVar_ counter (return . (+1)) let sharedIO = return sharedThunk _ <- runThreads sharedIO sharedIO n <- takeMVar counter if n == 1 then main else print n }}} Note that optimizations are turned off, so this isn't due to inlining. In fact, if I inline `sharedIO` and write {{{#!hs _ <- runThreads (return sharedThunk) (return sharedThunk) }}} instead, the problem disappears. So it seems that in order to reproduce the problem, two threads must race to evaluate an IO thunk containing an `unsafePerformIO` block; a race to evaluate the `unsafePerformIO` block is not sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 17:08:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 17:08:39 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.f1615b97ba058643de5e5b9d25e82402@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can this be closed as Not GHC then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 17:09:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 17:09:32 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.13e03e9baa3dfcf8fe499ca2ba373bc5@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: invalid | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Yes, I'd say so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 18:16:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 18:16:29 -0000 Subject: [GHC] #13052: unsafePerformIO duped on multithread if within the same IO thunk In-Reply-To: <046.4be60181dd029c0c19970eaecfa55541@haskell.org> References: <046.4be60181dd029c0c19970eaecfa55541@haskell.org> Message-ID: <061.207ded87e419c2d49b97bb2274bba1f9@haskell.org> #13052: unsafePerformIO duped on multithread if within the same IO thunk -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think there are conditions under which the GC will duplicate a closure. That seems like it could explain the behavior here, at least in part. That always bothered me slightly for other reasons (e.g. what if my cyclic data structure gets "unrolled" by this process and eventually consumes all my memory?) but this seems bad too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 19:01:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 19:01:48 -0000 Subject: [GHC] #13050: Holes don't work infix In-Reply-To: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> References: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> Message-ID: <066.4d50578fcf1bbc377fd739d64a08650a@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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:D2910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): Also the types inferred by holes can be confusing: {{{#!hs > :t 1 1 :: Num t => t > :t (+) 1 1 (+) 1 1 :: Num a => a > _ 1 1 Found hole: _ :: Integer -> Integer -> te }}} I would have expected: {{{ > _ 1 1 Found hole: _ :: (Num a) => a -> a -> te }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 19:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 19:16:34 -0000 Subject: [GHC] #13049: Make `-dead_strip` the default on Darwin In-Reply-To: <047.db5905269068938cc53fd620b92bef9f@haskell.org> References: <047.db5905269068938cc53fd620b92bef9f@haskell.org> Message-ID: <062.a3434b9bc8f1e17008c605f35e670dab@haskell.org> #13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | 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:D2911 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * differential: => Phab:D2911 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 1 19:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jan 2017 19:16:50 -0000 Subject: [GHC] #11040: Split SRT tables on Mac OS In-Reply-To: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> References: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> Message-ID: <060.366877f6f94d848215ae5e7c10bb5b10@haskell.org> #11040: Split SRT tables on Mac OS ---------------------------------+---------------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2911 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by dobenour): * differential: => Phab:D2911 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 00:30:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 00:30:39 -0000 Subject: [GHC] #13052: unsafePerformIO duped on multithread if within the same IO thunk In-Reply-To: <046.4be60181dd029c0c19970eaecfa55541@haskell.org> References: <046.4be60181dd029c0c19970eaecfa55541@haskell.org> Message-ID: <061.e1d746e7adefc790b57ac27165444c8b@haskell.org> #13052: unsafePerformIO duped on multithread if within the same IO thunk -------------------------------------+------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: The parallel GC may duplicate constructors and other immutable closures, but isn't it supposed to be careful not to duplicate thunks? Also I can reproduce this behavior (on Linux) with and without `+RTS -qg`, so the GC behavior doesn't seem to explain this completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 05:47:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 05:47:22 -0000 Subject: [GHC] #13053: Inferred type for hole is not general enough Message-ID: <043.cf65b094e9d5944cd08c3c4eddc36e84@haskell.org> #13053: Inferred type for hole is not general enough -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- As noted by @deech in #13050, inferred types for holes are sometimes not general enough. Example: {{{ Prelude> :set -XNoMonomorphismRestriction -- added this just to make sure Prelude> :t _ 1 2 :1:1: error: • Found hole: _ :: Integer -> Integer -> t Where: ‘t’ is a rigid type variable bound by the inferred type of it :: t at :1:1 • In the expression: _ In the expression: _ 1 2 }}} A more general type would be `(Num a, Num b) => a -> b -> t`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 05:47:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 05:47:54 -0000 Subject: [GHC] #13050: Holes don't work infix In-Reply-To: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> References: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> Message-ID: <066.f3b844d5dee0f184064c340e6a34e7f7@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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:D2910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): @deech I opened #13053 for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 06:51:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 06:51:03 -0000 Subject: [GHC] #13054: Generating unique names with template haskell Message-ID: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I need to use template haskell to generate a few instances where those instances each use a foreign function obtained from a particular {{{FunPtr}}}. As far as I'm aware, the only clean way to do this requires top level declarations of the form: {{{foreign import ccall "dynamic" makeFun1 :: FunPtr Foo -> Foo}}} If there was either: * Another way to do this without requiring top level named declarations. * The possibility to use these within a where clause (template haskell would suggest so given that it lets you use {{{Dec}}} within a {{{where}}}). Then I'd be fine probably be fine without names. I've tried using {{{newName}}} as it apparently generates fresh names but I cannot get it work for me. I've put a copy of the test case [https://gitlab.com/tim-m89/hs-th-name- issue here]. I compile with {{{stack build --ghc-options="-ddump-splices -ddump-to-file"}}} and the error is: {{{ th-name-issue/app/Main.hs:7:12: error: Multiple declarations of ‘makeFun’ Declared at: app/Main.hs:7:12 app/Main.hs:7:12 }}} Then I run {{{gvim .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/th- name-issue-exe/th-name-issue-exe-tmp/app/Main.dump-splices}}} And can see: {{{ app/Main.hs:7:12-25: Splicing declarations template-haskell-2.11.0.0:Language.Haskell.TH.Quote.quoteDec importGen " stuff here " ======> foreign import ccall safe "dynamic" makeFun_a3pc :: GHC.Ptr.FunPtr (Foreign.C.String.CString -> IO ()) -> Foreign.C.String.CString -> IO () foreign import ccall safe "dynamic" makeFun_a3pd :: GHC.Ptr.FunPtr (Foreign.C.String.CString -> IO ()) -> Foreign.C.String.CString -> IO () }}} Which suggests that I did manage to get unique names after all, so I don't know why it didn't compile?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 07:15:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 07:15:43 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.cb3df7682b5a8a71f165c35957ddebca@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 akio): I tested a [https://github.com/takano- akio/ghc/commit/930d42755e6753ba695157b96b8d651263b1934c a patch] and indeed marking `*FB` functions `INLINE[0]` seems to help. However this change increases binary sizes of some programs in nofib: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- gen_regexps -0.3% 0.0% 0.000 0.000 0.0% puzzle +0.8% 0.0% 0.089 0.090 0.0% reptile +0.8% -0.0% 0.008 0.008 0.0% -------------------------------------------------------------------------------- Min -0.3% -0.0% -7.3% -7.1% 0.0% Max +0.8% +0.0% +7.8% +7.7% +1.8% Geometric Mean +0.0% -0.0% +0.2% +0.2% +0.0% }}} I have only looked at the code for `puzzle` so far. The increase in the code size seems to come from inlining `efdtInt*FB` into a derived `Enum` instance declaration. I wonder if this change is acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 09:33:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 09:33:02 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.d424bccea4f41005a5795df2d54dadf7@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 nomeata): > I wonder if this change is acceptable. I’d say yes. The mean changes by <0.1%, and we really want fusion to be as reliable as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 10:36:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 10:36:57 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.53a2ff9b28588048f834a7b460e8781d@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: infoneeded 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): The truth tables for mod_ponens and mod_tollens are the same as the truth table of logical implication. For mod_ponens the entrance is at a=1 and the exit is at b=1. For mod_tollens the entrance is at b=0 and the exit is at a=0. mod_ponens is not like a conjonction likewise mod_tollens is not like a negative disjonction. They are rules of inference.[[BR]] Read mod_ponens like this: From A and (A implies B), infer B.[[BR]] And for mod_tollens read this: From (not B) and (A implies B), infer (not A).[[BR]] If you want more details read the Hilbert system which is a deductive reasoning, please.[[BR]] I looked in the archive mailing list about logical implication. Sometimes people get confused about the logical implication. If we write "if...then..." into a piece of code it is not a logical implication. If we talk and say "if...then..." we can suppose and deduce a logical implication. Do you understand the difference?[[BR]] In Haskell we can consider two things. Give a name to the function or name the function using a symbol. The name may be "imply" or "implies" or "impl" or other. The symbol can be ->. or -. or -|> or -|>. or -| or -|. or ->| or other.[[BR]] I am not running a second discussion on the logical implication. If the committee agree with the logical implication to be put in Haskell then it is ok and you can submit a patch instead of me. If the committee agree with mod_ponens and mod_tollens, idem. From my point of view, these three things have their place in the Haskell language.[[BR]] Happy new year! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 13:52:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 13:52:18 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.09ef56802a2638c4f5e563c937a6eb49@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | 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:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Hello, I have an implementation of this approach using `makeStatic`. It works most of the time, but I'm having some strange behavior when building with `--fno-full-laziness`. This is the test program: {{{ {-# LANGUAGE LambdaCase #-} {-# LANGUAGE StaticPointers #-} -- | A test to use symbols produced by the static form. module Main(main) where import GHC.StaticPtr main :: IO () main = do lookupKey (static (id . id)) >>= \f -> print $ f (1 :: Int) lookupKey :: StaticPtr a -> IO a lookupKey p = unsafeLookupStaticPtr (staticKey p) >>= \case Just p -> return $ deRefStaticPtr p Nothing -> error $ "couldn't find " ++ show (staticPtrInfo p) }}} At some intermediate phase, core looks like this: {{{ -- RHS size: {terms: 3, types: 2, coercions: 0} lvl_s2fm :: StaticPtr (Int -> Int) [LclId, Str=x] lvl_s2fm = base-4.10.0.0:GHC.StaticPtr.Internal.makeStatic @ (Int -> Int) lvl_s2fk lvl_s2fl -- RHS size: {terms: 3, types: 3, coercions: 0} p_aEP [OS=OneShot] :: StaticPtr (Int -> Int) [LclId] p_aEP = fromStaticPtr @ StaticPtr GHC.StaticPtr.$fIsStaticStaticPtr @ (Int -> Int) lvl_s2fm -- RHS size: {terms: 2, types: 2, coercions: 0} main_s2eP :: StaticKey [LclId] main_s2eP = staticKey @ (Int -> Int) p_aEP -- RHS size: {terms: 2, types: 2, coercions: 0} main_s2eO :: IO (Maybe (StaticPtr (Int -> Int))) [LclId, Arity=1] main_s2eO = unsafeLookupStaticPtr @ (Int -> Int) main_s2eP ... }}} Before the call to `makeStatic` is replaced with an entry in the static pointer table, a simplifier pass labeled as {{{ ==================== Simplifier ==================== Max iterations = 4 SimplMode {Phase = 2 [main], inline, rules, eta-expand, case-of-case} Result size of Simplifier = {terms: 42, types: 55, coercions: 9} }}} transforms it to {{{ -- RHS size: {terms: 17, types: 13, coercions: 0} lvl_s2fm :: StaticPtr (Int -> Int) [LclId, Str=x, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=NEVER}] lvl_s2fm = base-4.10.0.0:GHC.StaticPtr.Internal.makeStatic @ (Int -> Int) (GHC.StaticPtr.StaticPtrInfo (GHC.Base.build @ Char (\ (@ b_a2dI) -> GHC.CString.unpackFoldrCString# @ b "main"#)) (GHC.Base.build @ Char (\ (@ b_a2dI) -> GHC.CString.unpackFoldrCString# @ b "Main"#)) (GHC.Types.I# 13#, GHC.Types.I# 21#)) (\ (x_a2dj :: Int) -> x_a2dj) -- RHS size: {terms: 3, types: 5, coercions: 0} main_s32D :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [LclId, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] main_s32D = \ _ [Occ=Dead] -> case lvl_s2fm of wild_00 { } }}} which looks wrong, as the program becomes now a case with an empty list of alternatives. This is the definition of `makeStatic` {{{ module GHC.StaticPtr.Internal (makeStatic) where import GHC.StaticPtr {-# NOINLINE makeStatic #-} makeStatic :: StaticPtrInfo -> a -> StaticPtr a makeStatic (StaticPtrInfo pkg m (line, col)) _ = error $ "makeStatic: Unresolved static form at " ++ pkg ++ ":" ++ m ++ ":" ++ show line ++ ":" ++ show col }}} Perhaps the simplifier is somehow using the fact that `makeStatic` calls to error despite of the function being tagged with `NOINLINE`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 15:09:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 15:09:27 -0000 Subject: [GHC] #13042: Allow type annotations / visible type application in pattern synonyms In-Reply-To: <051.f33c40ad84d4e359a5f17d37eb1718de@haskell.org> References: <051.f33c40ad84d4e359a5f17d37eb1718de@haskell.org> Message-ID: <066.b0fcbffc1d947631d7639284cabca572@haskell.org> #13042: Allow type annotations / visible type application in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This ''is'' different. In my typical understanding of type application in patterns (forgetting about pattern synonyms for a moment), I think of type arguments only for ''existential'' type parameters. For example: {{{#!hs foo (Just @a x) = (x :: a) -- NO! `a` is universally bound bar (Just @Int x) = x -- NO! This looks like it's doing runtime type matching data E where MkE :: a -> E baz (MkE @a x) = ... -- OK. `a` is existential }}} The implicit proposal above includes visible type application for universals... but with different typing behavior than I had considered. I always thought that a pattern like `Just @Int x` would be some abominable pattern that matched against `Maybe a`, but then checked whether `a` was in fact `Int`. (This is just like how `Just True` only matches when the payload is in fact `True`.) For universals, though, there is a different typing interpretation: `Just @Int x` is a pattern against `Maybe Int`, and only `Maybe Int`. Trying to match something of type `Maybe a` against `Just @Int x` is a straightforward type error. What's challenging here is that modern patterns have arguments that go in both directions (that is, required vs provided). Normally, everything in a pattern is an output -- that is, something that is bound upon a successful pattern match. The one exception to this rule has been constructors, which are inputs. (View patterns are another way of providing inputs, which is why they are so interesting in the context of pattern synonyms.) Above is proposed adding universal type applications as inputs... an idea I think I like. A beautiful thing about adding universal type applications as inputs is that it greatly simplifies the design of type applications in patterns. I had been thinking that we allow type applications only for existential variables (as in my example above), but then the ordering of type applications might have a different meaning in a constructor expression than it would in a constructor pattern, which is very confusing. (See comment:1:ticket:11638 for further thoughts, as well as #11350 for the ticket about type applications in patterns in general.) Or have I utterly misunderstood the original post? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 15:16:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 15:16:06 -0000 Subject: [GHC] #13003: improve documentation for typed TH and make it more discoverable In-Reply-To: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> References: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> Message-ID: <060.7b486846d0882ece559aa519a69e3c05@haskell.org> #13003: improve documentation for typed TH and make it more discoverable -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | 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 think one could debate whether or not they should be under the same flag, but it's not clear to me that a new flag is needed. `-XTemplateHaskell` already enabled 4 different types of splices and quotes; typed TH just adds a fifth. In any case, I'm loath to break backward compatibility to fix this now. My suggestion about going via the mailing list is just to see what others think of this suggestion. Perhaps a list other than libraries@ is better. The problem is that I don't really trust my own instincts for this kind of user-facing design and would want to hear others weigh in. I'm not suggesting we go through an elaborate process -- I just want a few more voices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 16:24:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 16:24:36 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic Message-ID: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- If you add an `INLINABLE` pragma to `<**>` in `GHC.Base` then `stage2` fails to build with an `idInfo` panic. I don't really know where to begin debugging this but it seems quite bad! Here is a build where it fails: https://phabricator.haskell.org/harbormaster/build/17389/ Here is a branch with one commit with the change: https://github.com/ghc/ghc/tree/wip/inlinable-bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 16:46:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 16:46:00 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.9e7689ebba374d5cf9d3a6a17fb825f1@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): The panic. I don't know what you mean with `idInfo`. It was trying to build `libraries/transformers/dist- install/build/Control/Applicative/Backwards.o`. {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170102 for x86_64-unknown-linux): Iface Lint failure In interface for GHC.Base Unfolding of <**> : warning: In the expression: $ @ a @ b Kinds don't match in type application: Type variable: r_1i :: RuntimeRep Arg type: a :: * xx * : warning: In the expression: flip @ (a -> b) @ a @ b ($ @ a @ b) Argument value doesn't match argument type: Fun type: ((a -> b) -> a -> b) -> a -> (a -> b) -> b Arg type: forall (b :: TYPE a). (b -> b) -> b -> b Arg: $ @ a @ b <**> = \ (@ (f_a6mX :: * -> *)) (@ a_a6mY) (@ b_a6mZ) ($dApplicative_a6n0 :: Applicative f) -> liftA2 @ f @ a @ (a -> b) @ b $dApplicative_a6n0 (flip @ (a -> b) @ a @ b ($ @ a @ b)) Iface expr = \ @ f :: * -> * @ a @ b ($dApplicative :: Applicative f) -> liftA2 @ f @ a @ (a -> b) @ b $dApplicative (flip @ (a -> b) @ a @ b ($ @ a @ b)) }}} I'm not sure where `$ @ a @ b` came from but it seems to be treating `a` as the kind/representation argument when clearly it was intended to be the `a` in `(a -> b) -> a -> b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 16:51:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 16:51:00 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.f393878d8f164ce42d94050d7279a188@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by mpickering): Oh I see. That is more useful. I don't think my build locally was running the Iface Lint and so the panic was coming from somewhere different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 16:52:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 16:52:23 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.60f1c80dcce9303daa6232b62701ba63@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Ah I see. What does `./inplace/bin/ghc-stage2 --show-iface ./libraries/base/dist-install/build/GHC/Base.hi` have to say about `<**>`, for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 16:56:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 16:56:17 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.44d1eed6e20f2317f3da32faa25fae7d@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh never mind, the unfolding is in the panic. In a normal build, I have this unfolding information {{{ e8b07c72a9d4975f2b942de3da1a768e (<**>) :: Applicative f => f a -> f (a -> b) -> f b {- Arity: 3, HasNoCafRefs, Strictness: , Unfolding: InlineRule (3, True, False) (\ @ f :: * -> * @ a @ b ($dApplicative :: Applicative f) (eta :: f a) (eta1 :: f (a -> b)) -> <*> @ f $dApplicative @ (a -> b) @ b (fmap @ f ($p1Applicative @ f $dApplicative) @ a @ ((a -> b) -> b) (<**>1 @ a @ b) eta) eta1) -} 5729c051546f23f4fa0f6405530960ae <**>1 :: a -> (a -> b) -> b {- Arity: 2, HasNoCafRefs, Strictness: , Unfolding: InlineRule (2, True, True) (\ @ a @ b (x :: a) (y :: a -> b) -> y x) -} }}} so GHC optimized the unfolding, and it no longer mentions `($)` directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 21:59:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 21:59:32 -0000 Subject: [GHC] #12837: Disallow users to write instances for KnownNat and KnownSymbol In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.4a56769098d9e9c4b0099c14e456a5c2@haskell.org> #12837: Disallow users to write instances for KnownNat and KnownSymbol -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: sean Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2898 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"c5609577fab8a214c50561bea861c70d4bfd47c7/ghc" c5609577/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5609577fab8a214c50561bea861c70d4bfd47c7" Disallow users to write instances of KnownNat and KnownSym As noted in #12837, these classes are special and the user should not be able to define their own instances. Test Plan: Validate Reviewers: adamgundry, goldfire, mpickering, austin, bgamari Reviewed By: goldfire, mpickering Subscribers: goldfire, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2898 GHC Trac Issues: #12837 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 2 22:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jan 2017 22:45:06 -0000 Subject: [GHC] #12879: (xs -> xs) wrongly suggests TypeApplications In-Reply-To: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> References: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> Message-ID: <066.cb85d1d3de615f6b8e7a91a85d70a898@haskell.org> #12879: (xs -> xs) wrongly suggests TypeApplications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2877 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b28ca38e6e1d75f3c10cc593cdd2ac80ec29690f/ghc" b28ca38/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b28ca38e6e1d75f3c10cc593cdd2ac80ec29690f" Don't suggest enabling TypeApplications when it's already enabled Previously when encountering EAsPat in an expression context, TypeApplications was suggested even when already enabled. This patch replaces the suggestion with more appropriate message. Test Plan: validate Reviewers: austin, bgamari, mpickering, goldfire, simonpj Reviewed By: mpickering, goldfire, simonpj Subscribers: simonpj, goldfire, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2877 GHC Trac Issues: #12879 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 00:19:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 00:19:10 -0000 Subject: [GHC] #12837: Disallow users to write instances for KnownNat and KnownSymbol In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.1bc6022850e42d1cc672a25fc5e2bfc1@haskell.org> #12837: Disallow users to write instances for KnownNat and KnownSymbol -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: sean Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2898 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 02:16:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 02:16:05 -0000 Subject: [GHC] #12050: Allow haddock comments on non-record types In-Reply-To: <046.f6b7a2b632eb5ba65b0da9770c2d4b66@haskell.org> References: <046.f6b7a2b632eb5ba65b0da9770c2d4b66@haskell.org> Message-ID: <061.0b1f549172beff870d7a51add32d1216@haskell.org> #12050: Allow haddock comments on non-record types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8822 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): Watching this (is there a better way to subscribe) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 02:35:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 02:35:40 -0000 Subject: [GHC] #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) Message-ID: <045.69add10eda8bd8d6b058cda01bcfaac3@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This file never finishes compiling on GHC 8.0.1, and GHC 8.0.2 (dated 20161213): {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveFoldable #-} module Bug where import Data.Typeable import GHC.Generics import Data.Data data Condition v = Condition deriving (Functor, Foldable) data CondTree v c a = CondNode { condTreeData :: a , condTreeConstraints :: c , condTreeComponents :: [CondBranch v c a] } deriving (Functor, Foldable) data CondBranch v c a = CondBranch { condBranchCondition :: Condition v , condBranchIfTrue :: CondTree v c a , condBranchIfFalse :: Maybe (CondTree v c a) } deriving (Functor, Foldable) }}} The problem seems to be fixed in HEAD but I haven't looked for the commit that fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 02:37:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 02:37:26 -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.a1d72c726a9b6d127cfb2107969657a5@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -1,2 +1,2 @@ - This file never finishes compiling on GHC 8.0.1, and GHC 8.0.2 (dated - 20161213): + This file never finishes compiling with optimization (`-O`) on GHC 8.0.1, + and GHC 8.0.2 (dated 20161213): New description: This file never finishes compiling with optimization (`-O`) on GHC 8.0.1, and GHC 8.0.2 (dated 20161213): {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveFoldable #-} module Bug where import Data.Typeable import GHC.Generics import Data.Data data Condition v = Condition deriving (Functor, Foldable) data CondTree v c a = CondNode { condTreeData :: a , condTreeConstraints :: c , condTreeComponents :: [CondBranch v c a] } deriving (Functor, Foldable) data CondBranch v c a = CondBranch { condBranchCondition :: Condition v , condBranchIfTrue :: CondTree v c a , condBranchIfFalse :: Maybe (CondTree v c a) } deriving (Functor, Foldable) }}} The problem seems to be fixed in HEAD but I haven't looked for the commit that fixed it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 02:42:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 02:42:53 -0000 Subject: [GHC] #12050: Allow haddock comments on non-record types In-Reply-To: <046.f6b7a2b632eb5ba65b0da9770c2d4b66@haskell.org> References: <046.f6b7a2b632eb5ba65b0da9770c2d4b66@haskell.org> Message-ID: <061.807bb7b51e66dae6c23410e7f627805c@haskell.org> #12050: Allow haddock comments on non-record types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8822 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: shlevy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 03:40:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 03:40:01 -0000 Subject: [GHC] #13057: Build failing Message-ID: <045.b3a17eb55675244b7f61e193cc2719bc@haskell.org> #13057: Build failing -------------------------------------+------------------------------------- Reporter: salmon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I pulled changes and ran make. Received this error message for compiling utils/ghc-pkg/Main.hs. {{{ utils\ghc-pkg\Main.hs:1110:43: error: Not in scope: data constructor ‘AbiDependency’ Perhaps you meant ‘Dependency’ (imported from Distribution.Package) make[1]: *** [utils/ghc-pkg/ghc.mk:60: utils/ghc-pkg/dist/build/Main.o] Error 1 make: *** [Makefile:125: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 03:49:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 03:49:18 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault Message-ID: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.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: -------------------------------------+------------------------------------- We should be able to use {{{#!hs fmapDefault :: Traversable t => (a -> b) -> t a -> t b fmapDefault = (getId .) #. traverse .# (Id .) foldMapDefault :: (Traversable t, Monoid m) => (a -> m) -> t a -> m foldMapDefault = (getConst .) #. traverse .# (Const .) }}} where `.#` and `#.` are coercion operators found in `Data.Profunctor.Unsafe`. This should help when the function passed in doesn't inline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 04:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 04:31:10 -0000 Subject: [GHC] #11592: Self-kinded type variable accepted In-Reply-To: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> References: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> Message-ID: <061.582fbc42cda8385f0a8b3b706ab32e98@haskell.org> #11592: Self-kinded type variable accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * differential: => D2914 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 04:33:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 04:33:58 -0000 Subject: [GHC] #11592: Self-kinded type variable accepted In-Reply-To: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> References: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> Message-ID: <061.aba8e7b4c499926df14398bf66e39e02@haskell.org> #11592: Self-kinded type variable accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * differential: D2914 => Phab:D2914 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 04:51:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 04:51:47 -0000 Subject: [GHC] #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects In-Reply-To: <050.b7a046da7579b02aae5af1a75be2c102@haskell.org> References: <050.b7a046da7579b02aae5af1a75be2c102@haskell.org> Message-ID: <065.d1e0f792132aa3679fd887db8136de56@haskell.org> #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #11592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11592 Comment: This is a duplicate of #11592. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 04:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 04:56:52 -0000 Subject: [GHC] #12879: (xs -> xs) wrongly suggests TypeApplications In-Reply-To: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> References: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> Message-ID: <066.25d9a34d0b7f36d7c447bb8c5c8ba7e8@haskell.org> #12879: (xs -> xs) wrongly suggests TypeApplications -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2877 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 Tue Jan 3 04:58:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 04:58:06 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.4bcc475c5585cdfe4602e6ede43822aa@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Sounds reasonable to me. We already have most of the machinery needed to do this, since `(#.)` is [http://git.haskell.org/ghc.git/blob/8d63ca981f689463655766c252160d3fec160264:/libraries/base/Data/Functor/Utils.hs#l78 already used in base], located within the internal `Data.Functor.Utils` module. David, would you care to add `(.#)` as well and refactor `fmapDefault` and `foldMapDefault` as you propose? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:01:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:01:22 -0000 Subject: [GHC] #13057: Build failing In-Reply-To: <045.b3a17eb55675244b7f61e193cc2719bc@haskell.org> References: <045.b3a17eb55675244b7f61e193cc2719bc@haskell.org> Message-ID: <060.56d0deea4ad6f09ce2ad63f3f85b2e41@haskell.org> #13057: Build failing -------------------------------------+------------------------------------- Reporter: salmon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sanity check: did you also update the submodules via `git submodule update --init --recursive`? IIRC, `AbiDependency` is a fairly recent addition to `Cabal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:02:49 -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.af498b0162007bc97fa163c4fbe35370@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 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 RyanGlScott): * cc: RyanGlScott (added) Comment: Thanks for the report, ezyang. I'll look at this tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:05:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:05:58 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.5a9bb8b6942337ff3f5ae4af73c35917@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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 dfeuer): * owner: => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:50:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:50:06 -0000 Subject: [GHC] #13057: Build failing In-Reply-To: <045.b3a17eb55675244b7f61e193cc2719bc@haskell.org> References: <045.b3a17eb55675244b7f61e193cc2719bc@haskell.org> Message-ID: <060.e71634f469d404cc4a002cd72cd60d75@haskell.org> #13057: Build failing -------------------------------------+------------------------------------- Reporter: salmon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by salmon): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:52:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:52:18 -0000 Subject: [GHC] #13040: realToFrac into Complex Double has no specialization In-Reply-To: <043.c94211249f15fe3699809040311c3bb2@haskell.org> References: <043.c94211249f15fe3699809040311c3bb2@haskell.org> Message-ID: <058.81f08b4f581e03f4a89d53ecb0c932bd@haskell.org> #13040: realToFrac into Complex Double has no specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: akio Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Phab:D2901 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5800b02a1910a468485b272a2063377e8b06ee1d/ghc" 5800b02a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5800b02a1910a468485b272a2063377e8b06ee1d" Add specialization rules for realToFrac on Complex This patch implements RULES that specialize realToFrac at these 2 types: `(Real a) => a -> Complex Double` `(Real a) => a -> Complex Float` Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2901 GHC Trac Issues: #13040 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:52:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:52:18 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.c81be0abd37f259b17803b88a9f09c62@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"683ed475964bbd90030deb8f738370ae90b48a22/ghc" 683ed47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="683ed475964bbd90030deb8f738370ae90b48a22" Don't use $ in the definition of (<**>) in GHC.Base ($) is special as Richard explains in the note at the top of the page. However, when adding the note he didn't remove this usage. Normally it didn't cause any problems as the optimiser optimised it away. However if one had the propensity to stick one's fingers into the depths of the inliner, it caused horrible idInfo panics. Reviewers: rwbarton, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2913 GHC Trac Issues: #13055 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 05:52:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:52:48 -0000 Subject: [GHC] #13040: realToFrac into Complex Double has no specialization In-Reply-To: <043.c94211249f15fe3699809040311c3bb2@haskell.org> References: <043.c94211249f15fe3699809040311c3bb2@haskell.org> Message-ID: <058.122a928bca0a04a4400e996df084aeec@haskell.org> #13040: realToFrac into Complex Double has no specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: akio Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | 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): Phab:D2901 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 Tue Jan 3 05:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 05:53:17 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.01f6b075fd717baa64d62866357d63b5@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: high | 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 Tue Jan 3 12:35:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 12:35:57 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.7157412e8b246b30dd53a0a411d1358b@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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 ekmett): Sounds good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 13:25:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 13:25:36 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.de45ed55d8bb02bea224f4bb24bb7d43@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by domenkozar): * cc: domenkozar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 14:59:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 14:59:39 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.063d7804253503de5d5be319a07e0cf9@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 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: #12918 | Differential Rev(s): Phab:D2682, Wiki Page: | Phab:D2786 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in dae769049f67fdc3aff92cb828206d4c68faa2cf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 15:02:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 15:02:08 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS In-Reply-To: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> References: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> Message-ID: <061.3625b2a9d1b59419d764e007073bb732@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I believe this shouldn't be reproducible in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 15:12:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 15:12:08 -0000 Subject: [GHC] #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir In-Reply-To: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> References: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> Message-ID: <065.c15613e000e0fa8632260581eb22843e@haskell.org> #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 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: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: I'm going to let this slide for 8.0.2 given that it is non-essential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 15:12:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 15:12:50 -0000 Subject: [GHC] #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC In-Reply-To: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> References: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> Message-ID: <057.791a70353ca83b3ee7e8c9b2869b6fa8@haskell.org> #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: AIX | Architecture: powerpc Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I have reverted the commit in question in 55dfd21e1969b4b8e40196ecf29e4c9c73273966. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 16:30:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 16:30:21 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.97d676ad002a229370baecf7f8e78711@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12595 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I did a bit of digging into what is happening here: early in simplification we have the core, {{{#!hs scServerState [InlPrag=NOINLINE] :: SCServerState scServerState = ... foo_s1Sx :: State# RealWorld -> (# State# RealWorld, Int #) foo_s1Sx = \ (eta_B1 [OS=OneShot] :: State# RealWorld) -> case case scServerState of _ [InlPrag=NOINLINE, Occ=Dead] { SCServerState ipv_s1S8 -> GHC.Tuple.() } of _ [Occ=Dead] { () -> ... }}} Eventually case-of-case (and perhaps something else) fires, giving us, {{{#!hs foo_s1Sx = \ (eta_B1 [OS=OneShot] :: State# GHC.Prim.RealWorld) -> case scServerState of scServerState [InlPrag=NOINLINE] { SCServerState ipv_s1S8 -> case scServerState of _ [Occ=Dead] { SCServerState ds_d1Qj -> ... }}} Note that we are now shadowing the `scServerState` binder. This already seems suspicious. This then gets transformed to a `let` by the lifted case elimination simplification (see `Note [Case elimination: lifted case]`), {{{#!hs -- from phase foo_s1Sx = \ (eta_B1 [Dmd=, OS=OneShot] :: State# GHC.Prim.RealWorld) -> let { scServerState [InlPrag=NOINLINE, Dmd=] :: SCServerState [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] scServerState = scServerState } in case scServerState of _ [Occ=Dead, Dmd=] { SCServerState ds_d1Qj [Dmd=] -> ... }}} The let-bound `scServerState` is then floated to the top-level, resulting in the duplicate closures we see here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 16:32:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 16:32:00 -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.929cbb21beb1a7518aee4400cdf1603a@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving-perf Comment: Here's a stripped-down version that doesn't use any GHC extensions: {{{#!hs module Bug where newtype CondTree a = CondNode { condTreeComponents :: [CondBranch a] } data CondBranch a = CondBranch { condBranchIfTrue :: CondTree a , condBranchIfFalse :: CondTree a } instance Foldable CondBranch where foldr f_a3sF z_a3sG (CondBranch a1_a3sH a2_a3sI) = (\ b1_a3sJ b2_a3sK -> foldr f_a3sF b2_a3sK b1_a3sJ) a1_a3sH ((\ b3_a3sL b4_a3sM -> foldr f_a3sF b4_a3sM b3_a3sL) a2_a3sI z_a3sG) foldMap f_a3sN (CondBranch a1_a3sO a2_a3sP) = mappend (foldMap f_a3sN a1_a3sO) (foldMap f_a3sN a2_a3sP) instance Foldable CondTree where foldr f_a3sQ z_a3sR (CondNode a1_a3sS) = (\ b3_a3sT b4_a3sU -> foldr (\ b1_a3sV b2_a3sW -> foldr f_a3sQ b2_a3sW b1_a3sV) b4_a3sU b3_a3sT) a1_a3sS z_a3sR foldMap f_a3sX (CondNode a1_a3sY) = foldMap (foldMap f_a3sX) a1_a3sY }}} This shows that the program doesn't loop forever, but rather it just takes a long time to compile: {{{ $ time /opt/ghc/8.0.1/bin/ghc -O1 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) real 0m3.331s user 0m3.280s sys 0m0.044s }}} Adding more polymorphic recursion increases compilation time exponentially. For example, this program (with a modified definition and `Foldable` instance for `CondBranch`): {{{#!hs module Bug where newtype CondTree a = CondNode { condTreeComponents :: [CondBranch a] } data CondBranch a = CondBranch { condBranchIfTrue :: CondTree a , condBranchIfFalse :: Maybe (CondTree a) } instance Foldable CondBranch where foldr f_a3sL z_a3sM (CondBranch a1_a3sN a2_a3sO) = (\ b1_a3sP b2_a3sQ -> foldr f_a3sL b2_a3sQ b1_a3sP) a1_a3sN ((\ b5_a3sR b6_a3sS -> foldr (\ b3_a3sT b4_a3sU -> foldr f_a3sL b4_a3sU b3_a3sT) b6_a3sS b5_a3sR) a2_a3sO z_a3sM) foldMap f_a3sV (CondBranch a1_a3sW a2_a3sX) = mappend (foldMap f_a3sV a1_a3sW) (foldMap (foldMap f_a3sV) a2_a3sX) instance Foldable CondTree where foldr f_a3sY z_a3sZ (CondNode a1_a3t0) = (\ b3_a3t1 b4_a3t2 -> foldr (\ b1_a3t3 b2_a3t4 -> foldr f_a3sY b2_a3t4 b1_a3t3) b4_a3t2 b3_a3t1) a1_a3t0 z_a3sZ foldMap f_a3t5 (CondNode a1_a3t6) = foldMap (foldMap f_a3t5) a1_a3t6 }}} has twice the compilation time. {{{ $ time /opt/ghc/8.0.1/bin/ghc -O1 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) real 0m6.489s user 0m6.396s sys 0m0.092s }}} Now to find the commit responsible for fixing this and backport it to GHC 8.0.3. I have a hunch that it's the same commit that fixed #12234, but it'll be nice to confirm it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 17:35:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 17:35:43 -0000 Subject: [GHC] #13059: High memory usage during compilation Message-ID: <049.ca0b5011a23d544f2c8147b153a2791e@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 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: -------------------------------------+------------------------------------- I'm building stack using GHC 8.0.2-rc2 and noticed store uses 5.17GB of (RSS) memory during https://github.com/fpco/store/blob/master/src/Data/Store/Internal.hs compilation step. Using GHC 8.0.1 memory goes up to only 1.6GB. I haven't dug deeper, but something suspicious is going on. You should be able to reproduce using installed Nix and executing nix- build -A haskell.packages.ghc802.store '' using recent channel. Building haddock for store also goes up to 5.8GB. It'd be great if someone is able to reproduce this using plan GHC 8.0.2-rc2 See also https://github.com/fpco/store/issues/91 for upstream bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 18:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 18:24:01 -0000 Subject: [GHC] #13054: Generating unique names with template haskell In-Reply-To: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> References: <046.cab92fb9718af01c3a3ff4e0ae0e0c01@haskell.org> Message-ID: <061.178f5107d4e89d4a038a48fc5c4a43ab@haskell.org> #13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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): `newName` is intended for producing local names only, not anything top- level. I'm not surprised that it runs into trouble when you're using it at top-level. In a terrible horrible no-good workaround, my `th-desugar` library exports {{{ -- | Like newName, but even more unique (unique across different splices), -- and with unique @nameBase at s. Precondition: the string is a valid Haskell -- alphanumeric identifier (could be upper- or lower-case). newUniqueName :: Quasi q => String -> q Name newUniqueName str = do n <- qNewName str qNewName $ show n }}} This should fix your problem but is a sad, sad thing. The whole `newName` facility needs an update. Waiting for copious free time to do so! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 19:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 19:15:18 -0000 Subject: [GHC] #13060: Visible type application doesn't work for functions with inferred types Message-ID: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> #13060: Visible type application doesn't work for functions with inferred types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/feuerbach/.ghci Prelude> :set -XTypeApplications -fprint-explicit-kinds -fprint-explicit- foralls Prelude> :t id id :: forall {a}. a -> a Prelude> :t id @Int id @Int :: Int -> Int Prelude> let foo :: a -> a; foo = id Prelude> :t foo foo :: forall {a}. a -> a Prelude> :t foo @Int foo @Int :: Int -> Int Prelude> let bar = id Prelude> :t bar bar :: forall {a}. a -> a Prelude> :t bar @Int :1:1: error: • Cannot apply expression of type ‘a0 -> a0’ to a visible type argument ‘Int’ • In the expression: bar @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 20:03:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 20:03:13 -0000 Subject: [GHC] #13060: Visible type application doesn't work for functions with inferred types In-Reply-To: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> References: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> Message-ID: <063.17cd440b1f3280025ef38ea3dcad0d63@haskell.org> #13060: Visible type application doesn't work for functions with inferred types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: 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): This is by design, but there are two competing elements of the design at work here: 1. We really don't want type application to work with inferred types, as doing so would be very very fragile in the general case. See Section 3 of the [http://cs.brynmawr.edu/~rae/papers/2016/type-app/visible-type-app.pdf Visible Type Applications] paper. 2. In GHC 8.0, GHCi forgets information about the distinction between specified and inferred type variables, by design. See comment:16:ticket:11376 and below. The short version is that Simon advocated for the current design (which instantiates all types and then regeneralizes), while I advocated for just reporting the type. I lost the debate, and so GHCi loses information about type variables. These two design points lead to the confusing (but correct) interaction above. The good news is that HEAD (and, therefore, GHC 8.2) will have `:type +v`, which will not instantiate. You will see that `:type +v id` reports `forall a. a -> a` and `:type +v bar` reports `forall {a}. a -> a`, making the difference between these types clear(er). To be honest, I'm not sure if there's any way to make this clearer to users, who are understandably befuddled by your interaction. (Hence my standpoint in the debate in the commentary on #11376.) Concrete suggestions are very welcome. Otherwise, feel free to close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 20:35:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 20:35:08 -0000 Subject: [GHC] #13060: Visible type application doesn't work for functions with inferred types In-Reply-To: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> References: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> Message-ID: <063.74205722d46760efa6b32168624f9845@haskell.org> #13060: Visible type application doesn't work for functions with inferred types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Feuerbach): * status: new => closed * resolution: => invalid Comment: Thanks Richard, this makes sense. I agree that depending on the inferred order of type variables in actual code would be a bad idea. In my case, I was just trying to evaluate something quickly in ghci like this: {{{ *Main> description decoGrid :64:1: error: • Ambiguous type variable ‘a0’ arising from a use of ‘description’ prevents the constraint ‘(LayoutModifier (Decoration DefaultDecoration DefaultShrinker) a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instance exist: one instance involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: description decoGrid In an equation for ‘it’: it = description decoGrid :64:13: error: • Ambiguous type variable ‘a0’ arising from a use of ‘decoGrid’ prevents the constraint ‘(Eq a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Eq XEvent -- Defined in ‘Graphics.X11.Xlib.Event’ instance Eq FontSet -- Defined in ‘Graphics.X11.Xlib.Extras’ instance Eq FontStruct -- Defined in ‘Graphics.X11.Xlib.Font’ ...plus 61 others ...plus 138 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘description’, namely ‘decoGrid’ In the expression: description decoGrid In an equation for ‘it’: it = description decoGrid *Main> :t decoGrid decoGrid :: forall {a}. Eq a => ModifiedLayout (Decoration DefaultDecoration DefaultShrinker) Grid a *Main> -- ok, so I need to apply decoGrid to the right type param *Main> description (decoGrid @Window) :67:14: error: • Cannot apply expression of type ‘ModifiedLayout (Decoration DefaultDecoration DefaultShrinker) Grid a0’ to a visible type argument ‘Window’ • In the first argument of ‘description’, namely ‘(decoGrid @Window)’ In the expression: description (decoGrid @Window) In an equation for ‘it’: it = description (decoGrid @Window) *Main> -- this works: *Main> :set -XPartialTypeSignatures -Wno-partial-type-signatures *Main> description (decoGrid :: _ Window) "DefaultDecoration Grid" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 20:46:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 20:46:00 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance Message-ID: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: Constraint, | Operating System: Unknown/Multiple UndecidableInstances, | FlexibleInstances | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a class has an instance in the form F a => G a in its file, and no other instances, then the functions in G a will have the constraint F a, rather than G a. Example file {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class A a where f :: a -> a instance {-# OVERLAPPABLE #-} Eq a => A a where f = id }}} f will have type Eq a => a -> a -> Bool If we add: {{{#!hs instance A Int where f = id }}} Then f will have the type A a => a -> a -> Bool. A function of type A a => ... will always be rejected unless Eq is also included -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 20:46:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 20:46:23 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.c673723a1a8533cf4053024eae367875@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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 JCarr: @@ -16,1 +16,2 @@ - If we add: {{{#!hs + If we add: + {{{#!hs New description: If a class has an instance in the form F a => G a in its file, and no other instances, then the functions in G a will have the constraint F a, rather than G a. Example file {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class A a where f :: a -> a instance {-# OVERLAPPABLE #-} Eq a => A a where f = id }}} f will have type Eq a => a -> a -> Bool If we add: {{{#!hs instance A Int where f = id }}} Then f will have the type A a => a -> a -> Bool. A function of type A a => ... will always be rejected unless Eq is also included -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 20:47:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 20:47:09 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.2a8c83b88c7f753051e0eab0cd7a4b36@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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 JCarr: @@ -14,1 +14,3 @@ - f will have type Eq a => a -> a -> Bool + f will have type Eq a => a -> a -> Bool. + A function of type A a => ... will always be rejected unless Eq is also + included. @@ -21,3 +23,1 @@ - Then f will have the type A a => a -> a -> Bool. - A function of type A a => ... will always be rejected unless Eq is also - included + Then f will have the correct type A a => a -> a -> Bool. New description: If a class has an instance in the form F a => G a in its file, and no other instances, then the functions in G a will have the constraint F a, rather than G a. Example file {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class A a where f :: a -> a instance {-# OVERLAPPABLE #-} Eq a => A a where f = id }}} f will have type Eq a => a -> a -> Bool. A function of type A a => ... will always be rejected unless Eq is also included. If we add: {{{#!hs instance A Int where f = id }}} Then f will have the correct type A a => a -> a -> Bool. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:05:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:05:41 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance. Adding more clarification of inconsistency (was: Incorrect constraints given single flexible undecidable instance) In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.27df83b205cdfee8453580cacca9e462@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance. Adding more clarification of inconsistency -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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 JCarr): * type: bug => feature request @@ -15,2 +15,10 @@ - A function of type A a => ... will always be rejected unless Eq is also - included. + Consider the functions + {{{#!hs + g :: A a => a -> a + g = f + h :: A a => a -> a + h = let f' = f in f + i = f' where + f' = f + }}} + h and i will both fail to typecheck. @@ -24,0 +32,4 @@ + + This has been closed previously, but the contrast between g and h above is + worth the reconsideration, as it makes some valid functions not definable + unless an instance is added. New description: If a class has an instance in the form F a => G a in its file, and no other instances, then the functions in G a will have the constraint F a, rather than G a. Example file {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class A a where f :: a -> a instance {-# OVERLAPPABLE #-} Eq a => A a where f = id }}} f will have type Eq a => a -> a -> Bool. Consider the functions {{{#!hs g :: A a => a -> a g = f h :: A a => a -> a h = let f' = f in f i = f' where f' = f }}} h and i will both fail to typecheck. If we add: {{{#!hs instance A Int where f = id }}} Then f will have the correct type A a => a -> a -> Bool. This has been closed previously, but the contrast between g and h above is worth the reconsideration, as it makes some valid functions not definable unless an instance is added. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:07:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:07:20 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance. (was: Incorrect constraints given single flexible undecidable instance. Adding more clarification of inconsistency) In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.43b3d55176aed3d8a01d6da192c54248@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance. -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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 JCarr: @@ -17,1 +17,1 @@ - g :: A a => a -> a + g, h, i :: A a => a -> a @@ -19,1 +19,0 @@ - h :: A a => a -> a New description: If a class has an instance in the form F a => G a in its file, and no other instances, then the functions in G a will have the constraint F a, rather than G a. Example file {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class A a where f :: a -> a instance {-# OVERLAPPABLE #-} Eq a => A a where f = id }}} f will have type Eq a => a -> a -> Bool. Consider the functions {{{#!hs g, h, i :: A a => a -> a g = f h = let f' = f in f i = f' where f' = f }}} h and i will both fail to typecheck. If we add: {{{#!hs instance A Int where f = id }}} Then f will have the correct type A a => a -> a -> Bool. This has been closed previously, but the contrast between g and h above is worth the reconsideration, as it makes some valid functions not definable unless an instance is added. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:08:08 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance. In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.25fa965e0fbf2888d299d6584338c457@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance. -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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 JCarr): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:11:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:11:42 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance. In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.12b215edf807c602683a4d698826bc81@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance. -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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 JCarr: @@ -31,4 +31,0 @@ - - This has been closed previously, but the contrast between g and h above is - worth the reconsideration, as it makes some valid functions not definable - unless an instance is added. New description: If a class has an instance in the form F a => G a in its file, and no other instances, then the functions in G a will have the constraint F a, rather than G a. Example file {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} class A a where f :: a -> a instance {-# OVERLAPPABLE #-} Eq a => A a where f = id }}} f will have type Eq a => a -> a -> Bool. Consider the functions {{{#!hs g, h, i :: A a => a -> a g = f h = let f' = f in f i = f' where f' = f }}} h and i will both fail to typecheck. If we add: {{{#!hs instance A Int where f = id }}} Then f will have the correct type A a => a -> a -> Bool. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:13:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:13:42 -0000 Subject: [GHC] #13060: Visible type application doesn't work for functions with inferred types In-Reply-To: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> References: <048.6a09fcc849524f3539c46789a73b0a1b@haskell.org> Message-ID: <063.db517e18f013f170f2cc8384c3dab9d2@haskell.org> #13060: Visible type application doesn't work for functions with inferred types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well (I don't know whether this is documented anywhere but) that should not be the confusing part--`forall {a}.` means you can't use a type application to specify the type. The confusing part is the behavior of `:t id` and `:t foo`. But `:info` will show you the difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:19:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:19:51 -0000 Subject: [GHC] #13061: Incorrect constraints given single flexible undecidable instance. In-Reply-To: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> References: <044.c126e56ae530a6b093172610b3eacc40@haskell.org> Message-ID: <059.4ab1d7031ea24d9613d7064c286fcf16@haskell.org> #13061: Incorrect constraints given single flexible undecidable instance. -------------------------------------+------------------------------------- Reporter: JCarr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Constraint, Resolution: | UndecidableInstances, | FlexibleInstances 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): Interesting. This happens because when you bind a variable with `let`/`where`, GHC simplifies the type. In your case, it simplifies `A a => a -> a` to `Eq a => a -> a`, choosing the `Eq a => A a` instance. This is a bit bogus, though, because `Eq a => a -> a` is not actually more general than `A a => a -> a` in the presence of other instances. I'm not sure what to do here, really. I think this may just be an oddity of `FlexibleInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 3 21:59:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jan 2017 21:59:13 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) Message-ID: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: LLVM | Operating System: Linux Optimiser -11 | Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building [https://hackage.haskell.org/package/unicode-transforms] it fails with: {{{ cabal: Entering directory '/tmp/cabal-tmp-7667/unicode-transforms-0.2.0' Configuring unicode-transforms-0.2.0... Building unicode-transforms-0.2.0... Preprocessing library unicode-transforms-0.2.0... [ 1 of 12] Compiling Data.Unicode.Properties.DecompositionsK ( Data/Unicode/Properties/DecompositionsK.hs, dist/build/Data/Unicode/Properties/DecompositionsK.o ) [ 2 of 12] Compiling Data.Unicode.Properties.Decompositions ( Data/Unicode/Properties/Decompositions.hs, dist/build/Data/Unicode/Properties/Decompositions.o ) [ 3 of 12] Compiling Data.Unicode.Properties.DecomposableK ( Data/Unicode/Properties/DecomposableK.hs, dist/build/Data/Unicode/Properties/DecomposableK.o ) `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) cabal: Leaving directory '/tmp/cabal-tmp-7667/unicode-transforms-0.2.0' }}} Other details: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ opt --version LLVM (http://llvm.org/): LLVM version 3.7.1 Optimized build. Default target: armv7l-unknown-linux-gnueabihf Host CPU: (unknown) }}} I already submitted an issue to the package's bug tracker, but it is believed to be a GHC bug: [https://github.com/harendra-kumar/unicode- transforms/issues/10] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 00:31:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 00:31:57 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.f3e9a43b16a5f54b2cca172f036a462a@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12595 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: I'm going to bump this off until a possible 8.0.3. It's unfortunate that such a regression will be present in 8.0.2, likely the last release in the 8.0 series, but I just can't afford to push the release at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 01:08:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 01:08:25 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.dce82b8f072e3f466e6409685fb5916a@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -5,3 +5,3 @@ - https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives - links to similar examples. https://ghc.haskell.org/trac/ghc/ticket/10528 - comment:13 gives more background. + https://ghc.haskell.org/trac/ghc/ticket/11688, especially + ticket:11688#comment:7 which gives links to similar examples. + ticket:10528#comment:13 gives more background. New description: Make it possible to apply GHC rewrite rules to class methods. As Conal wrote in a discussion on glasgow-haskell-users, it is too bad that we can't use class laws as optimizations in the form of rewrite rules. In that same thread Simon PJ referenced https://ghc.haskell.org/trac/ghc/ticket/11688, especially ticket:11688#comment:7 which gives links to similar examples. ticket:10528#comment:13 gives more background. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 01:16:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 01:16:12 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.b4603cd0f538168c276ed478dfe15ea2@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -2,3 +2,4 @@ - wrote in a discussion on glasgow-haskell-users, it is too bad that we - can't use class laws as optimizations in the form of rewrite rules. In - that same thread Simon PJ referenced + wrote in a discussion on [[https://mail.haskell.org/pipermail/glasgow- + haskell-users/2016-November/026406.html|glasgow-haskell-users]], it is too + bad that we can't use class laws as optimizations in the form of rewrite + rules. In that same thread Simon PJ referenced New description: Make it possible to apply GHC rewrite rules to class methods. As Conal wrote in a discussion on [[https://mail.haskell.org/pipermail/glasgow- haskell-users/2016-November/026406.html|glasgow-haskell-users]], it is too bad that we can't use class laws as optimizations in the form of rewrite rules. In that same thread Simon PJ referenced https://ghc.haskell.org/trac/ghc/ticket/11688, especially ticket:11688#comment:7 which gives links to similar examples. ticket:10528#comment:13 gives more background. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 01:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 01:24:20 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.b96c70a95ddf1f784faacda86d5f86b8@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * milestone: ⊥ => 8.2.1 Comment: Setting a milestone because osa1 is working actively in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 01:35:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 01:35:22 -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.96db120f994d37f7c4227cd99778827a@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12234 Comment: Indeed, commit 517d03e41b4f5c144d1ad684539340421be2be2a (which fixed #12234) also fixed this issue. I was a bit skeptical that it would, since I thought #12234 only applies in cases of coercibility-solving for newtypes, and the original program doesn't appear to use any newtypes. But then it occurred to me - the original program actually //does// involve newtypes, but they're hidden in the default definitions of some `Foldable` class methods: {{{#!hs class Foldable t where -- | The largest element of a non-empty structure. maximum :: forall a . Ord a => t a -> a maximum = fromMaybe (errorWithoutStackTrace "maximum: empty structure") . getMax . foldMap (Max #. (Just :: a -> Maybe a)) -- | The least element of a non-empty structure. minimum :: forall a . Ord a => t a -> a minimum = fromMaybe (errorWithoutStackTrace "minimum: empty structure") . getMin . foldMap (Min #. (Just :: a -> Maybe a)) -- | The 'sum' function computes the sum of the numbers of a structure. sum :: Num a => t a -> a sum = getSum #. foldMap Sum -- | The 'product' function computes the product of the numbers of a -- structure. product :: Num a => t a -> a product = getProduct #. foldMap Product }}} And `(#.)` is defined to be: {{{#!hs (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c) (#.) _f = coerce }}} Quite sneaky. Until we can get 517d03e41b4f5c144d1ad684539340421be2be2a backported to GHC 8.0.3, a workaround is to manually define these `Foldable` methods for polymorphically recursive datatypes such that they don't use `coerce`: {{{#!hs {-# LANGUAGE CPP #-} module Bug where import Data.Maybe (fromMaybe) newtype CondTree a = CondNode { condTreeComponents :: [CondBranch a] } data CondBranch a = CondBranch { condBranchIfTrue :: CondTree a , condBranchIfFalse :: Maybe (CondTree a) } instance Foldable CondBranch where foldr f z (CondBranch a1 a2) = foldr f (foldr (flip (foldr f)) z a2) a1 foldMap f (CondBranch a1 a2) = mappend (foldMap f a1) (foldMap (foldMap f) a2) #if MIN_VERSION_base(4,8,0) sum = foldr (+) 0 product = foldr (*) 1 minimum = fromMaybe (error "minimum: empty") . foldr (min . Just) Nothing maximum = fromMaybe (error "maximum: empty") . foldr (max . Just) Nothing #endif instance Foldable CondTree where foldr f z (CondNode a) = foldr (flip (foldr f)) z a foldMap f (CondNode a) = foldMap (foldMap f) a #if MIN_VERSION_base(4,8,0) sum = foldr (+) 0 product = foldr (*) 1 minimum = fromMaybe (error "minimum: empty") . foldr (min . Just) Nothing maximum = fromMaybe (error "maximum: empty") . foldr (max . Just) Nothing #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 01:38:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 01:38:27 -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.0640b422de1586de16fc304ed1384107@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | 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 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13056 Comment: #13056 demonstrates another occurrence of this bug, this time involving `Foldable`. But unlike the program in this ticket, it doesn't require any GHC extensions like `UndecidableInstances` to trigger it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 01:45:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 01:45:35 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.a7ffd4087e047f8b7280f30914ef482c@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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's difficult to investigate this issue at the moment, given that it relies on a package with a high number of dependencies and a module with a lot of code. It would be tremendously helpful if you could isolate a smaller test case (preferably with one module with no dependencies other than what ships with GHC) that exhibits the issue. As a start, you can try commenting out code from `Data.Store.Internal` and see if there's a definition or group of definitions that triggers the memory spike. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 02:43:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 02:43:48 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.5f2b5de444f9df2be054557fabecc0f5@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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: D2916 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab: D2916 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 02:46:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 02:46:36 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.351764fda03866ec4e28c4620cbcb3e6@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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:D2916 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab: D2916 => Phab:D2916 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 03:52:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 03:52:24 -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.00e82d3d2f7c8d1eb23b6762c87892b7@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Thanks for the speedy triage! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 05:56:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 05:56:33 -0000 Subject: [GHC] #13063: Program uses 8GB of memory Message-ID: <047.30ffe259e5b1cc90f33cfba9e08ebbbc@haskell.org> #13063: Program uses 8GB of memory -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this repo with stack build it uses 8GB of memory. Even using -O0 it runs quickly but uses 8GB of memory: https://github.com/codygman/frames-example-cdi I've attached a -ddump-simple-iterations log of this build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 06:12:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 06:12:45 -0000 Subject: [GHC] #13063: Program uses 8GB of memory In-Reply-To: <047.30ffe259e5b1cc90f33cfba9e08ebbbc@haskell.org> References: <047.30ffe259e5b1cc90f33cfba9e08ebbbc@haskell.org> Message-ID: <062.1b9f0dc07c5feef26ec6d5b435e3aa78@haskell.org> #13063: Program uses 8GB of memory -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by codygman): The log is 1.8GB and failed to upload, but heres a google drive link: https://drive.google.com/file/d/0B7kqAY5hrqDwZzJnbXVvX2x2d1k/view?usp=sharing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 09:02:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 09:02:37 -0000 Subject: [GHC] #13032: Redundant forcing of Given dictionaries In-Reply-To: <046.811080f481e777da656f14add09b1cc8@haskell.org> References: <046.811080f481e777da656f14add09b1cc8@haskell.org> Message-ID: <061.24cda54c3bfacb925f4321f028d2b884@haskell.org> #13032: Redundant forcing of Given dictionaries -------------------------------------+------------------------------------- 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): Let's leave aside the deferred-type-error case for now. Other than that, I claim that '''every evidence variable should be non- bottom''', and so * Can be evaluated strictly, and/or * Its evaluation can be discarded if its payload is not required This is true even of recursively-defined dictionaries; see `Note [Recursive superclasses]` in `TcInstDcls`. (A recursively-defined dictionary may be infinite, so you can't evaluate it hyper-strictly, but it should not be bottom.) But dictionaries still ''can'' be defined recursively (unlike say unboxed values). Now, I believe all this is true of the programs generated by source Haskell, but nothing in Core checks this invariant; and in Core you could certainly declare a bottom dictionary `(let d = d in ...)`. I don't know how to make it a statically-checkable invariant of Core, but I expect that it'd be possible to make a decent conservative approximation that was enough to capture the programs generated from source Haskell. There's even an old flag `-fdicts-strict` that I would like to get back to, which flirted with using call-by-value for evidence variables; c.f. #2436 That leaves deferred type errors. But let's not allow the tail to wag the dog. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 10:42:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 10:42:23 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312578=3A_Update_links_to_SPJ?= =?utf-8?b?4oCZcyBwYXBlcnM=?= In-Reply-To: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> References: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> Message-ID: <061.83d428a67a6b747d4c6ea77a71d86cd2@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => worksforme Comment: It looks as if the old links work again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 10:51:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 10:51:29 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.e90517af697197dfb138ffbd2bcc682f@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | 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): Currently, rewrite rules, as well as unfolding (i.e. inlining) are active in certain phases, which are currently counted down from, I belive, 3 to 0. Exending this system of phases to something more expressive has always been a thought. Maybe it would help here? The smallest delta that might help is simply adding a a number of extra phases, say, from 7 to 4. The compiler would annotate all type class dictionary access functions (i.e. class methods) with `INLINE [~4]`, which would prevent them from being rewritten to the actual implementation. Then rewrite rules active in phases 7, 6 and 5 would have a pretty good chance of applying to class methods. Would this work? Obviously, one might want nicer ways of specifying phases (i.e. fixed names, or even arbitrary news with ordering constraints), but that is a slightly orthogonal discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 11:08:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 11:08:25 -0000 Subject: [GHC] #13053: Inferred type for hole is not general enough In-Reply-To: <043.cf65b094e9d5944cd08c3c4eddc36e84@haskell.org> References: <043.cf65b094e9d5944cd08c3c4eddc36e84@haskell.org> Message-ID: <058.de116f9e0e94b7ee0004806a94001398@haskell.org> #13053: Inferred type for hole is not general enough -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is Haskell's defaulting rule at work. See section 4.3.4 of the [https://www.haskell.org/onlinereport/haskell2010/ haskell report], and GHCi's [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #type-defaulting-in-ghci extended defaulting rules]. I suppose that there could be some modification of the rule to prevent defaulting taking place if there were holes lying around... but I'm not sure exactly what the modification would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 11:20:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 11:20:38 -0000 Subject: [GHC] #13055: Adding INLINABLE pragma causes GHC panic In-Reply-To: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> References: <049.99589d9c0d95b7648d3335bd6e3be46a@haskell.org> Message-ID: <064.c0b825f4ec668ca50e86b15ed88f760f@haskell.org> #13055: Adding INLINABLE pragma causes GHC panic -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: high | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm very confused about this. The comment at the top of `GHC.Base` says {{{ NOTA BENE: Do NOT use ($) anywhere in this module! The type of ($) is slightly magical (it can return unlifted types), and it is wired in. But, it is also *defined* in this module, with a non-magical type. GHC gets terribly confused (and *hangs*) if you try to use ($) in this module, because it has different types in different scenarios. This is not a problem in general, because the type ($), being wired in, is not written out to the interface file, so importing files don't get confused. The problem is only if ($) is used here. So don't! }}} (It should jolly well have a `Note` heading so we can refer to it.) But I don't understand that. The wired-in definition should override the local one, even in the module it is defined in. I'd love a better understanding of what goes wrong. But life is short, I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 12:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 12:28:11 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning Message-ID: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- 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: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 12:28:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 12:28:43 -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.18a5c2e4b0135c94439fa2ddc06be89e@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ryan you are so fast! Could you add your stripped-down tests as a performance regression test? Probably redundant, but always good to check that we don't accidentally break it again. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 13:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 13:45:48 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.f6b9af1c58b0feef53f763955a65e25c@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | 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 don't think there is anything fundamentally difficult here. Class methods have a special rewriting rule (see `MkId.dictSelRule`, which is not as well documented as it should be). It rewrites `op dict`, where `op` is a class method and `dict` is a dictionary, when possible to the type-specialised function. All we need to do is to stop that rule firing immediately. Perhaps it can fire in phase 2 (and hence 1 and 0) instead of always. That would give other rules a chance to match on it. I can't forsee all the consequences, but they should not be too drastic. But it would need careful perf testing; failure to optimise overloading can kill performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 14:21:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 14:21:37 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.eb065a948b698ede9a9d35efd31c7594@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm afraid I'm lost. You say "but `Binary Value` instance is imported from `Data.Binary.Orphans`"; but the error message explicitly says {{{ except perhaps to import instances from ‘Data.Binary.Orphans’ }}} so I don't see a problem. In general given a set of imports that is redundant, there isn't a unique way to remove imports to eliminate the redundancy. For example if I import modules `A` and `B` which both export `f` and I use `f` but nothing else from either `A` or `B`, then either the import of `A` or of `B` can be removed, but not both. In such cases GHC has to make a choice about which import to report as redundant. In your example it seems that GHC's choice changed between versions, probably having to do with the fact that you mentioned `Binary` in an explicit import list. I'm pretty sure that if you reverse the order of your two `import Data.Binary` lines, GHC 7.10.3 will give the same error you are getting with GHC 8.0.1. In any case the solution is to add an empty import list as the error message suggests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 14:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 14:33:22 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.df0722ef69d8175114d9b07c9c23d82a@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | 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 bgamari): The limitation described here leads to quite a bit of boilerplate in GHC itself to ensure that users can write rules against, e.g. `(==)`. See, for instance, `GHC.Int.eqInt64`. Moreover, I have seen a number of well-known packages (`text` being one example) which mistakenly try to match overloaded operators in their rewrite rules. Thankfully we now produce warnings in these cases, but previously these were latent performance bugs just waiting to be noticed. It would be great to eliminate this sharp edge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 15:43:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 15:43:49 -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.21d6a06f9c1e8182d7374ee93b7e8b9e@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | 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): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:16:50 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.e9cd2ee2b20d771f581976d373baf61d@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `opt` is the LLVM optimizer, not part of GHC. If it's exiting with exit code -11 that's almost certainly due to a segfault, which in turn is almost certainly due to it running out of memory, seeing as you're building on an ARM system and the source file contains a 72KB-long list literal. How much RAM does your build system have? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:22:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:22:54 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.f52ea1dfdd646ab25008fe311497e1bc@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by rwbarton): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:26:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:26:36 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances Message-ID: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: Generics | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- User-defined `Generic` and `Generic1` instances are problematic. === They are susceptible to breakage === Some details of the classes may change between GHC versions, and indeed have done so in the past. User-defined instances are likely to break in the face of various such "internal" changes. This is one reason why `Data.Sequence`, for example, does not have a `Generic` instance. === They require potentially-expensive consistency checks === GHC cannot assume that every type has at most one `Generic` and `Generic1` instance, so it needs to look for possible alternatives at instance resolution time. According to Simon (and maybe also Simon), this may be partly responsible for the performance regressions seen in Phab:D2899. === Downsides === Prohibiting user-defined instances does have some costs. Suppose a type was originally defined concretely, exposing its constructors and a `Generic` instance. The implementer may decide later to make the type abstract, and export pattern synonyms to retain the same interface. But the `Generic` instance will either change or disappear. Someone relying on that instance could be in trouble. If the instance disappears, they'll be forced to write code by hand that they didn't need to before. If it changes, their code may change its behavior unexpectedly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:28:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:28:03 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.4fd24d0199e57a90594919c62b8c6436@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:31:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:31:17 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.96c34d135e5f7984ddf06466786357f3@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: RyanGlScott (added) Comment: I'd like to know what Ryan Scott thinks of this idea. We have some classes (like `Typeable`) where you can't give user instances, but it seems less clear-cut for `Generic`. The efficiency issue is to do with the costs of doing the type-family consistency checks for all the `Generic` instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:33:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:33:21 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.f888e85a27c6a61bb1ce6f9bba19fba5@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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 rwbarton): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:36:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:36:17 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.b423a7ef18aa360889bccd56e50187aa@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yes, sorry. I forgot the real troubles were `Rep` and `Rep1` rather than `Generic` and `Generic1`. One possible variation might be to disassociate the families from the classes, and only restrict the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:41:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:41:10 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.89a0c950f060af8adef57e94a532cbf0@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * component: Package system => Build System Comment: This sort of happened for 8.0.1 after all: there's a new package description field `dynamic-library-dirs` for the location of the shared library and by default Cabal now uses the `$LIBDIR/lib$PKG_KEY.so` layout suggested in this ticket. As I understand it this doesn't yet apply to the libraries distributed with GHC, though; but at least the number of libraries this affects is now constant (~25, rather than however many hundred dependencies a non-GHC program might have). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 17:54:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 17:54:05 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.7f8784a35ad29cacc5c8b5cba484baff@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): If I reverse `Data.Binary` and `Data.Binary.Orphans` imports the error messages stay exactly the same. What I see, is that GHC 8.0.1 doesn't follow the spec in https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/UnusedImports > - import Foo dominates import Foo(x). (You could also argue that the reverse should hold.) > - Otherwise choose the textually first one. `import Data.Binary.Orphans` should dominate `import Data.Binary (Binary (..))` when we check where from `Binary` is imported. Either commentary or implementation is incorrect. I suspect the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:02:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:02:15 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.fc7b4200f01339ee2df2ce4a19cdf418@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | ErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => goldfire Comment: Has there been any motion on this Richard? If not is it safe to say that this won't be fixed for 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:04:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:04:58 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.e9ac60f37b697e6c12b4880bd2f3ecda@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I believe I support the general idea in this proposal, although I'd like to add some clarifications to the reasons you've listed. Clarification number one is that hand-written `Generic` instances are already forbidden as of GHC 7.10, provided you have the `Safe` extension enabled. ----- Replying to [ticket:13065 dfeuer]: > User-defined `Generic` and `Generic1` instances are problematic. Agreed. `Generic` is truly unique in that any given `Generic` instance can and should be determined solely by the algebraic structure of the datatype. Any other use of `Generic` is an abuse of its intended purpose, in my opinion. > === They are susceptible to breakage === > Some details of the classes may change between GHC versions, and indeed have done so in the past. User-defined instances are likely to break in the face of various such "internal" changes. This is one reason why `Data.Sequence`, for example, does not have a `Generic` instance. It's true that we've changed the internal details of `GHC.Generics` before, but believe me when I say that we tried to preserve backwards compatibility as much as possible :) There are a good many other breaking changes we //could// make, but we haven't yet (see #7492). With CPP, it's actually quite feasible to maintain fancy type-level generics hackery all the way back to GHC 7.2. That being said, I would argue that `Data.Sequence` shouldn't have a `Generic` instance for a different reason: it's an abstract type. A `Generic` instance necessarily leaks every implementation detail about your datatype, so having a `Generic` instance for an abstract type is nonsense. > === They require potentially-expensive consistency checks === > GHC cannot assume that every type has at most one `Generic` and `Generic1` instance, so it needs to look for possible alternatives at instance resolution time. According to Simon (and maybe also Simon), this may be partly responsible for the performance regressions seen in Phab:D2899. If we're pursing this goal in the name of compiler performance (see also #12731, which I believe is very relevant here), we need to be careful in stating our goals. As I stated [https://ghc.haskell.org/trac/ghc/ticket/12731#comment:3 here], it wouldn't be enough to disallow hand-written `Generic` instances. You'd also need to check that there's only one `Generic` instance per datatype, lest you end up with a scenario like this (which is currently possible in GHC 8.0): {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE StandaloneDeriving #-} import GHC.Generics data Foo a = Foo a deriving instance {-# OVERLAPPABLE #-} Generic (Foo a) deriving instance {-# OVERLAPPING #-} Generic (Foo Int) }}} > === Downsides === > Prohibiting user-defined instances does have some costs. Suppose a type was originally defined concretely, exposing its constructors and a `Generic` instance. The implementer may decide later to make the type abstract, and export pattern synonyms to retain the same interface. But the `Generic` instance will either change or disappear. Someone relying on that instance could be in trouble. If the instance disappears, they'll be forced to write code by hand that they didn't need to before. If it changes, their code may change its behavior unexpectedly. I don't follow this argument. If the definition of a datatype changes, then either it's `Generic` instance must change, or you should just remove the `Generic` instance altogether. Full stop. Anything else would be a lie. ----- To contribute one more "downside" of this proposal, drawing from my own experience, there is only one scenario where I've found hand-written `Generic` instances to be necessary: backwards compatibility. In old versions of GHC, there were numerous bugs that prevented you from deriving `Generic` instances for sufficiently polykinded datatypes, forcing you to resort to manual implementation. But these bugs have all been squashed, AFAICT, so I don't see any reason why we'd need to worry about this going forward. In fact, manually implementing `Generic` instances is precisely how the `generic-deriving` library allows you to define `Generic` instances via Template Haskell (in case `deriving Generic` is buggy on an old GHC). So if we did implement this proposal, that part of `generic-deriving` would no longer work. But that's a sacrifice I think I'd be OK with. ----- If we do decide to press on with this propsal, let's not let this Trac ticket be the end of the discussion. Let's advertise this change as a concrete GHC proposal first. I bet there's someone out there who is relying on hand-written `Generic` instances who hasn't spoken up, and I'd hate to break their code without warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:07:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:07:19 -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.07580e99ce3cb2c3605376c3d1e92af0@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12808 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:08:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:08:23 -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.2296bcfabfe0fca2485d471394903df0@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 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): * priority: normal => high * owner: => goldfire Comment: Richard should be taking care of this as part of the levity polymorphism work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:15:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:15:32 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.1a392fb15d7bfa83820a181a3a9c6019@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | ErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No motion on this, I'm afraid. I'd love to get to this by 8.2, believe me. Can't swear to it, as I'm prioritizing the levity polymorphism stuff. I've left my work [https://github.com/goldfirere/ghc/tree/irreducible-hetero here]. There's a chance that rebasing that patch might just work, given the changes to the solver in the meantime. (I gave up because of a solver loop, and my memory just barely tells me that I thought at the time that the loop wasn't my fault.) I'll at least check this possibility soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:23:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:23:12 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.3db1affbe50f5d58943fb248154ae456@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > If I reverse `Data.Binary` and `Data.Binary.Orphans` imports the error messages stay exactly the same. Even in GHC 7.10.3? If so, then doesn't 7.10.3 also violate that spec? Then again, that spec is 8 years old and the intended behavior may have changed in that time. Better to check the User's Guide. (I haven't checked myself to see whether it has anything to say about this, but I hope so--if not that's also a bug.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:24:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:24:22 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.dd16e121d78b9b9ee2fe57e21d83f89e@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Sorry, my first two sentences are nonsense. I still would not go by that old wiki page, though. What does the User's Guide say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:27:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:27:42 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.7d3df628c4ca3cb01dcaf92204169ac4@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can you comment on why this is different from our stance on `Data`, which addresses largely similar problems but for which custom instances are apparently approved (e.g., `Data.Map.Map` has one)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:30:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:30:06 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.8ba6f2689ac4073026e107e3eb355ea2@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Wunused-imports not much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:40:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:40:13 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.dcff156d465953bf4d5eb2b615c52d03@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, that's not very helpful. But considering that the User's Guide does not document the exact heuristics used to select which imports are unused, the behavior of GHC seems to be correct here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:50:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:50:45 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.f72332d3a86c8ed48df3b12f230c929e@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not as experienced with `Data.Data` as I am with `GHC.Generics`, so take my comments with a grain of salt. But the impression that I've gathered after working with it a little bit is that `Data.Data` has slightly different goals than `GHC.Generics`. With the former (`Data`), you mostly care about generically walking over data structures. That seems to explain why `Data.Data` gives you only a bare-minimum amount of metadata for each datatype and constructor, as they're only useful insofar as they serve as signposts when you're deep in a datatype traversal. Moreover, the documentation in `Data.Data` mentions the phrase "public representation" in several places. It seems acceptable to lie a little in certain `Data` instances—e.g., in primitive datatypes like `Int`, or abstract types like `Map`—in order to give programmers //some// interface that they can walk over. With the latter (`Generic`), there's an expectation that the representation type provides a faithful view of the datatype's structure and metadata. It occurs to me that we really don't state this expectation anywhere in the documentation, but this is nonetheless the reasoning that David Terei alluded to when he made the change to disallow hand-written `Generic` instances in 578fbeca31dd3d755e24e910c3a7327f92bc4ee3. If we allow users to hand-write their `Generic` instances, then I feel that we are allowing them to shoot themselves in the foot. Of course, the other thing that `Data` and `Generic` have in common is that they facilitate the ability to reduce boilerplate code. But even if you can't write `Generic` instances for your abstract types, you can still use `GHC.Generics` to help reduce boilerplate: just use the `Generic` instance for an isomorphic type. For instance, if you want to think of `Data.Map` as a list of key-value pairs, then you have the power to do so: {{{#!hs module Main (main) where import Data.Map import Generics.Deriving.Eq import GHC.Generics eqMapKVList :: (GEq k, GEq v) => Map k v -> Map k v -> Bool eqMapKVList x y = geq (toListRep x) (toListRep y) where toListRep :: Map k v -> Rep [(k, v)] () toListRep = from . toList main :: IO () main = do print $ eqMapKVList (fromList [('a', 'b')]) (fromList [('a', 'b')]) print $ eqMapKVList (fromList [('a', 'b')]) (fromList [('a', 'c')]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 18:56:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 18:56:06 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.c6fed77df68c35b4e25077b34dce4c59@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: The original version of mwc-random and the minimized test cases in the comments are a bit fragile, in that they rely crucially on `blocks` being floated out of the IO action which contains it, ideally to top level. I'm not sure why, but GHC 7.8.4 isn't doing this floating out in the versions marked SLOW. For better or worse, GHC 7.10.1 does float out `blocks` to top level in the SLOW versions, and I also checked that it produces efficient code for the original version mwc-random-0.13.1.0 that prompted this report. Without a way to reproduce this in a recent version, I'm going to assert that the underlying issue was probably fixed between 7.8 and 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 19:48:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 19:48:31 -0000 Subject: [GHC] #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) In-Reply-To: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> References: <045.6fe81b99a732ea595c519e1d0b94d988@haskell.org> Message-ID: <060.664270cd0539720b90aedaa6546a42a5@haskell.org> #13062: `opt' failed in phase `LLVM Optimiser'. (Exit code: -11) -------------------------------------+------------------------------------- Reporter: 2bdkid | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: LLVM | Optimiser -11 Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by 2bdkid): Replying to [comment:1 rwbarton]: > `opt` is the LLVM optimizer, not part of GHC. If it's exiting with exit code -11 that's almost certainly due to a segfault, which in turn is almost certainly due to it running out of memory, seeing as you're building on an ARM system and the source file contains a 72KB-long list literal. How much RAM does your build system have? This is a Raspberry Pi 2 and it only has 1GB of ram. Is there any documentation for opt exit codes? I can't find any through Google -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 20:19:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 20:19:50 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.3300795158f32149f7df34c4e2b1fb8b@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): That's unfortunate. But if it's not documented, I'd like to try to fix heuristics to be more of 7.10, does anyone have a pointers to where to look? The warnings really help refactoring with big (and constantly growing) company-prelude. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 20:49:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 20:49:18 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.32dc4e4e268379e12dbaef31833e05bb@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The right function to look at is `warnUnusedImportDecls` in `RnNames`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 20:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 20:50:30 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.75d113613ba4a7ada994bcfc8ff9433e@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 20:53:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 20:53:34 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.ed3442e25edad6cb3ac3cb684fbb5368@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There's a little-known file `nofib/Simon-nofib-notes` that contains per- benchmark commentary. Could you add the info above to it? The notes concentrate on aspects of nofib that have proved fragile, and are supposed to stop you reinventing the wheel when you are investigating a nofib perf blip. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 20:55:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 20:55:01 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.8b4ebf3a6c8aab104876231a5cfc042a@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record this was merged to 8.0.2 as 498009a904a1e8910f9e0e527f6eb6c8073c8a76. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 21:11:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 21:11:43 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.9ad0d3a3c669e7b0a01f0bd423db285c@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for looking at this. The first thing to do is to work out the ''specification''. The current spec is indeed the one at [wiki:Commentary/Compiler/UnusedImports]. If you are happy with the spec, but the code does not implement it, then produce a small test case (preferably not depending on a complicated library) that demonstrates the problem. Then you are set to look for what is going wrong. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 21:27:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 21:27:27 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.547f7a1010ec285b100b487955df1147@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): (I also gave a new proposal for redundant imports at https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/RelaxedUnusedImports which is not implemented yet but might be worth looking at.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 22:03:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 22:03:45 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.64be09a6cacbc095a4befe61a6ec0755@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Sorry if I am being dense here. I still don't understand why you care ''which'' import is reported as redundant. If you are only importing a module for its instances, writing an empty import list is the standard way to express that explicitly. It seems like the reason has to do with the fact that `Data.Binary.Orphans` provides instances you want that are not provided by `Data.Binary`, while `Data.Binary` does not provide any instances you want that are not provided by `Data.Binary.Orphans`. In the case of a custom prelude, "want" might even just mean that you want to make them available to your importers. So, there is no way for GHC to divine your intent in general. It certainly doesn't seem like this distinction between the two modules is related to whether or not you provide a (nonempty) explicit import list. So if you change the heuristics to handle this case to your satisfaction, it will just break a symmetric case for someone else. All in all, it seems like a lot of effort to avoid typing `()`. The RelaxedUnusedImports proposal is rather different in intent, since there the goal is to make it easier to write warning-free code across a range of versions of dependencies, while this issue is not about whether to issue a warning, but which warning to issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 4 23:30:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jan 2017 23:30:19 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.e789237fb505704531d97733ebd0b687@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by geraint): I presume this means "What version of libgmp are you using?" and is directed at me. No idea, before you asked I wasn't aware of libgmp: how do I tell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 01:04:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 01:04:27 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.5666b32024aadc735c71fb3f7fbd8817@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: fixed | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as f6e8d45d6860996e7db9dcd4b440eabac710fa5e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 01:08:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 01:08:59 -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.bffb2c5a3e8a51226e02046c5adffd7d@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: 8.0.2 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 bgamari): Yes, I strongly suspect that this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 03:01:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 03:01:42 -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.469aeb1cea86f8c3d03492a28c1b8514@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 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: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2917 Comment: I've made a temporary workaround in Phab:D2917. I can patch `libiberty` for `8.4`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 03:42:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 03:42:59 -0000 Subject: [GHC] #13066: Backpack doesn't check for fixity consistency Message-ID: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> #13066: Backpack doesn't check for fixity consistency -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This should fail, but instead it prints 7. {{{ unit p where signature A where infixl 6 `mul` infixl 7 `plu` mul :: Int -> Int -> Int plu :: Int -> Int -> Int module P where import A x = 2 `mul` 3 `plu` 1 unit i where module A where infixl 7 `mul` infixl 6 `plu` mul :: Int -> Int -> Int mul x y = x * y plu :: Int -> Int -> Int plu x y = x + y unit main where dependency p[A=i:A] module Main where import P main = print x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 03:45:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 03:45:28 -0000 Subject: [GHC] #13067: Abstract closed type families don't work with Backpack Message-ID: <045.d425a29a2949d9aaec22378dc47e66ba@haskell.org> #13067: Abstract closed type families don't work with Backpack -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This should typecheck: {{{ {-# LANGUAGE TypeFamilies #-} unit p where module A where type family ClosedFam a where ClosedFam a = Int unit sig where signature A where type family ClosedFam a where .. unit main where dependency sig[A=p:A] }}} but instead we confusingly report: {{{ foo.bkp:9:9: error: Type constructor ‘ClosedFam’ has conflicting definitions in the module and its hsig file Main module: type family ClosedFam a :: * Hsig file: type family ClosedFam a :: * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 03:47:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 03:47:40 -0000 Subject: [GHC] #10838: hsig files don't have good enough error checking for wired-in types In-Reply-To: <045.41f34a07c7f54dad24eaa71df940bd49@haskell.org> References: <045.41f34a07c7f54dad24eaa71df940bd49@haskell.org> Message-ID: <060.a39f9ce5f5cd9972dd61acd093cf10a1@haskell.org> #10838: hsig files don't have good enough error checking for wired-in types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: This is fixed in the latest implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 03:53:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 03:53:18 -0000 Subject: [GHC] #12189: sigof01m broken after D2030 In-Reply-To: <046.54adf8bccbc2ab3ebb885505fcfa0227@haskell.org> References: <046.54adf8bccbc2ab3ebb885505fcfa0227@haskell.org> Message-ID: <061.8430421ea1563e3deee529310b85d96f@haskell.org> #12189: sigof01m broken after D2030 -------------------------------------+------------------------------------- Reporter: niteria | Owner: ezyang 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: sigof01m Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Should be fixed now. (In any case, the sigof01 test was obsoleted by the new Backpack implementation.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 03:54:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 03:54:01 -0000 Subject: [GHC] #10680: Make Backpack order-independent (again) In-Reply-To: <045.acd19a6d5477bb093f22fa6506169d80@haskell.org> References: <045.acd19a6d5477bb093f22fa6506169d80@haskell.org> Message-ID: <060.2b8fb0532d46e60f9d00fe6bcf326767@haskell.org> #10680: Make Backpack order-independent (again) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: We did this, it works, hooray. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 04:19:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 04:19:48 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.4f14e0080bdcf63bb3271c94f53eb8fb@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: low | 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:D2595 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 05:41:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 05:41:42 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.50659f73afc30aab41a1a2c4dfb502ca@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): I found even more minimal examples, they aren't tied to instances: {{{ % cat Next.hs import Control.Applicative import Prelude (IO, pure) main :: IO () main = pure () % cat Next2.hs import Control.Applicative import Prelude (IO, pure) main :: IO () main = () <$ pure () % $(ghc-select ghc-7.10.3) % ghc -Wall -fforce-recomp Next.hs [1 of 1] Compiling Main ( Next.hs, Next.o ) Next.hs:2:1: Warning: The import of ‘pure’ from module ‘Prelude’ is redundant Linking Next ... % ghc -Wall -fforce-recomp Next2.hs [1 of 1] Compiling Main ( Next2.hs, Next2.o ) Next2.hs:2:1: Warning: The import of ‘pure’ from module ‘Prelude’ is redundant Linking Next2 ... % $(ghc-select ghc-8.0.1) % ghc -Wall -fforce-recomp Next.hs [1 of 1] Compiling Main ( Next.hs, Next.o ) Next.hs:1:1: warning: [-Wunused-imports] The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() Linking Next ... % ghc -Wall -fforce-recomp Next2.hs [1 of 1] Compiling Main ( Next2.hs, Next2.o ) Linking Next2 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 08:39:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 08:39:20 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.dc4ebf995b748dadf9012554561a2902@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Helpful example, thank you. Just for context, in comment:12, I guess `Control.Applicative` exports `pure` and `<$`. * So the use of `<$` needs `import Control.Applicative` * The use of `pure` could come from `import Prelude( IO, pure )` or from `import Control.Applicative`; but for some reason GHC 8 chooses the former, whereas the rules in wiki:Commentary/Compiler/UnusedImports says the latter. Is that your reasoning? Are you saying "I like the rules in wiki:Commentary/Compiler/UnusedImports, but they aren't being implemented", or are you saying "I'd like different rules"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 08:49:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 08:49:19 -0000 Subject: [GHC] #10262: Improve documentation of module signatures In-Reply-To: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> References: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> Message-ID: <062.22791d8ebe1b9d78cb75c542cac86a65@haskell.org> #10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2918 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2918 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 08:52:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 08:52:25 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.385ff1d8ffbdbabae013122f9929fbf6@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12595 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"baf9ebe55a51827c0511b3a670e60b9bb3617ab5/ghc" baf9ebe5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="baf9ebe55a51827c0511b3a670e60b9bb3617ab5" Ensure nested binders have Internal Names This is a long-standing bug. A nested (non-top-level) binder in Core should not have an External Name, like M.x. But - Lint was not checking this invariant - The desugarer could generate programs that failed the invariant. An example is in tests/deSugar/should_compile/T13043, which had let !_ = M.scState in ... This desugared to let ds = case M.scSate of M.scState { DEFAULT -> () } in case ds of () -> ... We were wrongly re-using that scrutinee as a case binder. And Trac #13043 showed that could ultimately lead to two top-level bindings with the same closure name. Alas! - The desugarer had one other place (in DsUtils.mkCoreAppDs) that could generate bogus code This patch fixes all three bugs, and adds a regression test. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 08:53:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 08:53:36 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.e04467bdd3545285e4318e35228f3377@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12595 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Turns out that my patch in comment:3 didn't cause the bug, but it did ''expose'' it. It's been there for ages! Anyway fixed now. Merge to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 08:53:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 08:53:58 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.a752dc0a6b0efe615a8b6f3dfb301d5a@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12595 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS thank you for a nice repro case -- made it far easier to find. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 09:07:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 09:07:44 -0000 Subject: [GHC] #13051: Make the Register Allocator Loop-Aware In-Reply-To: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> References: <046.bce1843df0d7916c2598d1667301fca7@haskell.org> Message-ID: <061.67ae5ada3df0ff670d6cdcddce86668a@haskell.org> #13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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:D2903 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 09:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 09:08:43 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.b400f29c1dc94a85e9973238448be1ac@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: | -------------------------------------+------------------------------------- Comment (by domenkozar): Thanks Ryan. I agree it's a hard starting point, I won't have time until late-Jan to further research the issue, but wanted to report the bug since store is a dependency of Stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 09:26:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 09:26:43 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.d305b04543a50601c5ac171cf60b5b93@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 simonpj): It's true that doing more inlining will generally improve things, but we could be a bit more forensic about this. Just sprinkling more inline pragmas, some of which may do no good, is a bit of a blunt instrument. I checked the code for `testFromThenTo`, compiled with -O, and got {{{ Foo.$wtestFromThenTo = \ (ww_s2vE :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<# ww_s2vE 0#) of { False -> case ww_s2vE of wild2_a2uk { __DEFAULT -> case GHC.Real.$wf1 10# wild2_a2uk of ww4_a2uE { __DEFAULT -> GHC.Enum.efdtIntUpFB @ (Int -> Int) (GHC.List.lengthFB @ Int) (id @ Int) 0# 2# ww4_a2uE Foo.testFromThenTo2 }; 0# -> Foo.testFromThenTo1 }; True -> GHC.Real.^2 } }}} Fusion has happened (there is a use of the `foldr/build` rule), but the call to `edftIntUpFB` remains. That's not necessarily bad. As you'll see, it's not a tiny function: {{{ efdtIntUpFB :: (Int -> r -> r) -> r -> Int# -> Int# -> Int# -> r efdtIntUpFB c n x1 x2 y -- Be careful about overflow! | isTrue# (y <# x2) = if isTrue# (y <# x1) then n else I# x1 `c` n | otherwise = -- Common case: x1 <= x2 <= y let !delta = x2 -# x1 -- >= 0 !y' = y -# delta -- x1 <= y' <= y; hence y' is representable -- Invariant: x <= y -- Note that: z <= y' => z + delta won't overflow -- so we are guaranteed not to overflow if/when we recurse go_up x | isTrue# (x ># y') = I# x `c` n | otherwise = I# x `c` go_up (x +# delta) in I# x1 `c` go_up x2 }}} BUT the bad thing is that it allocated loads of `Int` values! Why does it do that? Becuase the function passed to it (`c` in the above definition) takes an `Int` as its argument. So if `efdtIntUpFB` isn't inlined, it ''must'' allocate an `Int` box for every iteration. Bad! But this is an internal function. Suppose we gave it this signature: {{{ efdtIntUpFB :: (Int# -> r -> r) -> r -> Int# -> Int# -> Int# -> r -- ^^^ NB Int# not Int }}} Now it won't allocate! Can we make the rest of the pieces fit together now? Would you like to have a try? I also looked at the call to `lengthFB` in the above optimised code. It's defined like this: {{{ lengthFB :: x -> (Int -> Int) -> Int -> Int lengthFB _ r = \ !a -> r (a + 1) }}} Uh-ho! More `Int` boxes! So I tried rewriting the `length` moving parts (in `GHC.List`) like this: {{{ {-# INLINE xlength #-} xlength :: [a] -> Int xlength xs = I# (xlenAcc xs 0#) xlenAcc :: [a] -> Int# -> Int# xlenAcc [] n = n xlenAcc (_:ys) n = xlenAcc ys (n +# 1#) {-# RULES "xlength" [~1] forall xs . xlenAcc xs = foldr xlengthFB idXlength xs "xlengthList" [1] foldr xlengthFB idXlength = xlenAcc #-} -- The lambda form turns out to be necessary to make this inline -- when we need it to and give good performance. {-# INLINE [0] xlengthFB #-} xlengthFB :: x -> (Int# -> Int#) -> Int# -> Int# xlengthFB _ r = \ a -> r (a +# 1#) {-# INLINE [0] idXlength #-} idXlength :: Int# -> Int# idXlength x = x }}} That compiles fine. Even if it generates the same code as before, GHC will have to do less work to optimise it, so it's a win. Would you like to try that change to `length` and see if it is an improvement? Maybe you can do the same for `efdtIntUpFB`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 09:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 09:54:03 -0000 Subject: [GHC] #13066: Backpack doesn't check for fixity consistency In-Reply-To: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> References: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> Message-ID: <060.ed117505d923abe1f90ce8b2b2c96c89@haskell.org> #13066: Backpack doesn't check for fixity consistency -------------------------------------+------------------------------------- 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:D2919 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2919 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 10:07:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 10:07:06 -0000 Subject: [GHC] #13068: GHC should not allow modules to define instances of abstract type classes Message-ID: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> #13068: GHC should not allow modules to define instances of abstract type classes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | 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: -------------------------------------+------------------------------------- hs-boot files permit a type class to be given "abstractly", in which case any implementation of the type class is permissible. But it does not reject instances defined for such a class. {{{ -- A.hs-boot module A where class C a -- B.hs module B where import {-# SOURCE #-} A instance C Int where -- A.hs module A where import B class C a where f :: a -- Main.hs import A main = print (f :: Int) }}} I get this when I build with `--make`: {{{ ezyang at sabre:~$ ghc-head --make C.hs -fforce-recomp [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling Main ( C.hs, C.o ) Linking C ... ./B.o:(.data+0x0): undefined reference to `A_CZCC_con_info' collect2: error: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 10:07:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 10:07:30 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.67ff38f5788f339c89174d876fe4266f@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 akio): Hmm, you could eliminate allocation of `Int`s that way, but the code still has to allocate one function closure for each element in the list, right? It seems to me that inlining `efdtIntUpFB` is the only way to eliminate this allocation, if the final list consumer is `length` or `foldl'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 10:12:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 10:12:00 -0000 Subject: [GHC] #13069: hs-boot files permit default methods in type class Message-ID: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> #13069: hs-boot files permit default methods in type class -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack hs- | Operating System: Unknown/Multiple boot | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation claims you are not allowed to do so but the compiler does not reject it. {{{ ezyang at sabre:~$ cat A.hs-boot module A where class C a where f :: a -> a f x = x ezyang at sabre:~$ ghc-head -c A.hs-boot -fforce-recomp ezyang at sabre:~$ ghc-head --version The Glorious Glasgow Haskell Compilation System, version 8.1.20161218 }}} The same problem applies to hsig files (which combust more spectacularly) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 10:43:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 10:43:32 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.1ba4177237e048df59bdfdb45a3b2bb7@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 simonpj): I think perhaps you mean that in the call {{{ I# x `c` go_up (x +# delta) }}} since GHC doesn't know `c` is strict, it'll allocate a thunk for the second argument. Quite true. And that does mean it'd be good to inline `efdtIntUpFB`, I agree. But still, fewer Int boxes is better regardless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 10:52:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 10:52:55 -0000 Subject: [GHC] #13070: time after evaluation Message-ID: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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 {{{:set +s}}} gives the time after each evaluation.This time may have a difference of 68% in same calculation.It should not change after each evaluation of computation. Can we have a fixed and real time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 11:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 11:19:16 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.dd68bca0e8ee389b6b38e2e0161bc42a@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest 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 phadej): you have to compile doctests against the same compiler you are testing with. - A compiled ghc master - patched ghc-paths: https://github.com/simonmar/ghc-paths/pull/9 (not sure if actually necessary) - compiled doctest using just compiled ghc - `.../build/doctest/doctest libraries/base/Data/Maybe.hs` - profit {{{ Examples: 44 Tried: 44 Errors: 0 Failures: 0 }}} Maybe, Char and Either pass, Functor got: {{{ ### Failure in libraries/base/Data/Functor.hs:49: expression `show <$> Nothing' expected: "Nothing" but got: "" "\ESC[;1m:31:6: \ESC[;1m\ESC[31merror:\ESC[;1m" " Ambiguous occurrence \8216<$>\8217" " It could refer to either \8216Data.Functor.<$>\8217," " defined at libraries/base/Data/Functor.hs:73:1" " or \8216Prelude.<$>\8217," " imported from \8216Prelude\8217 (and originally defined in \8216Data.Functor\8217)\ESC[0m" }}} nasty colorcodes! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 11:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 11:20:55 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.4ef43f0ce808d103affda4eb73ae8790@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): That's exactly my reasoning. And: I like the rules in [wiki:Commentary/Compiler/UnusedImports]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 11:29:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 11:29:47 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.ba0b02f9d318816999e07ee1c2883fc4@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. Next: would you like to peer at the code in `RnNames.warnUnusedImportDecls` to see what is going wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 11:33:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 11:33:46 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.41e6569cbb6c5271465d4d3be694d12d@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): I'll do that, not right now though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 11:55:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 11:55:44 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.a480560865bae0caeb90d404f8bf1cf5@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 akio): > since GHC doesn't know c is strict, it'll allocate a thunk for the second argument. This is true. I was actually referring to another source of allocation: since the call to `c` is under-saturated, evaluating this call involves allocating a closure for the partial-application of `c`. This is also the case when the final consumer is `foldl'` instead of `length`. I think this is a general argument for marking *all* `FB` functions `INLINE [0]`. If `p = build pFB` is advertised as a good producer, a user would expect `foldl' f z p` to allocate no intermediate data structure. However, if `pFB` is not inlined, this expression will necessarily allocate a few closures for each eliminated cons cell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 12:15:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 12:15:45 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.c810c51cd70a6a19ea513252cd9ef074@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi @refold, Just checking in to see if you're still working on this. If not would you be able to let me know your last status? This is on the list of major Windows changes I want to target for 8.4. I assume this is your repository? https://github.com/23Skidoo/haskell-iocp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 13:54:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 13:54:55 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms Message-ID: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms ----------------------------------------+------------------------------- Reporter: taktoa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Loading this code: {{{#!hs {-# LANGUAGE PatternSynonyms #-} data D1 = MkD1 () data D2 = MkD2 D1 pattern P1 x = MkD1 x pattern P2 x = MkD2 (P1 x) }}} in GHCi 8.0.1 results in the following panic: {{{ $ ghci Broken.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Broken.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): kindPrimRep.go rep_a18s Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} The unique name in the error message (`rep_a18s`) seems to be consistent between executions, but varies after `:reload`ing. The panic does not occur when the module is simply compiled with `ghc`; it only occurs when loaded into `ghci`. According to ​Gergő Érdi, who is CCed, the error does not occur in GHCi 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 13:56:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 13:56:14 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.af3d7513b624bfbd2731efde0c9f79ee@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by cactus): We can simplify the code even further, and still have it crash GHCi: {{{ {-# LANGUAGE PatternSynonyms #-} data D1 = MkD1 data D2 = MkD2 D1 pattern P1 = MkD1 pattern P2 = MkD2 P1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:02:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:02:16 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.e2ed839a536cca029733ff71e0f197f1@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by taktoa): Looks like this might be a dupe of https://ghc.haskell.org/trac/ghc/ticket/12007 and https://ghc.haskell.org/trac/ghc/ticket/12017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:05:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:05:07 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.7203ab5ec19acbefde78b3837c193f46@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by simonpj): Yes, pls check with 8.0.2. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:09:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:09:50 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.0120edc125cf81f3905e43b902977847@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by rwbarton): A good question. I don't have a Mac but I think you can do the following. * Run `less $(which ghc)`. The second line should be of the form `exedir=".../bin"`. * Run `otool -L .../bin/ghc` using the path from above. Look for a line mentioning `libgmp`. `otool -l` might also have useful information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:10:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:10:33 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.394fb6b368b5f61714255a84d5cf5122@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by taktoa): I don't have easy access to GHC 8.0.2 (I'm on NixOS), but I tried it with GHC HEAD and the problem seems to be solved: {{{ ~ $ /nix/store/0sww5ii70bn8b8w3g8lszqn7pwxl4axs-ghc-8.1.20160930/bin/ghci Broken.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Broken.hs, interpreted ) Ok, modules loaded: Main. *Main> Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:11:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:11:09 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.05a66e0866601f02684389149d2b18ae@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by taktoa): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:11:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:11:53 -0000 Subject: [GHC] #5344: CSE should look through coercions In-Reply-To: <046.337028ce6bbff67a50874240336d3596@haskell.org> References: <046.337028ce6bbff67a50874240336d3596@haskell.org> Message-ID: <061.9be7bef9f2afc323310048697f3a6581@haskell.org> #5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: duplicate | Keywords: cse 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): * status: new => closed * resolution: => duplicate Comment: I think this is covered as good as it can be for now by doing CSE on STG, where the coercion is gone (see #9291). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:13:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:13:39 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.130708f96b1fdea14cfc471eb241c67e@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by mpickering): I am fairly certain this is solved in 8.0.2 as well. The 8.0.2 release candidate is on nixpkgs if you want to try, the attribute name is `haskell.compiler.ghc802`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:14:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:14:28 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.88c994ceb00d5d7ef7a4db5c9caa7298@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"19d5c7312bf0ad9ae764168132aecf3696d5410b/ghc" 19d5c73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19d5c7312bf0ad9ae764168132aecf3696d5410b" Add a CSE pass to Stg (#9291) This CSE pass only targets data constructor applications. This is probably the best we can do, as function calls and primitive operations might have side-effects. Introduces the flag -fstg-cse, enabled by default with -O for now. It might also be a good candiate for -O2. Differential Revision: https://phabricator.haskell.org/D2871 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:19:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:19:14 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.b66e867131f0ad90ec5da6a3edabf690@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Done. Would still be fun to be able to do this (and stuff like #5344) in Core, but that would require serious work on the type level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:22:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:22:06 -0000 Subject: [GHC] #5344: CSE should look through coercions In-Reply-To: <046.337028ce6bbff67a50874240336d3596@haskell.org> References: <046.337028ce6bbff67a50874240336d3596@haskell.org> Message-ID: <061.5e6e956ef09dec9945eda99f0fa0a11d@haskell.org> #5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: duplicate | Keywords: cse 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): Hah, you confused me by writing this comment before updating #9291 :) This example seems easier than the original example in #9291 though, since `f` can be expressed using a cast as a well-typed program in the current Core language. All else being equal, it seems better to do the CSE earlier rather than later, though I'm not sure whether it makes an actual difference in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:38:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:38:41 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.3d6352f79137322e808a15c6c2732a2f@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:42 Joachim Breitner ]: > In [changeset:"19d5c7312bf0ad9ae764168132aecf3696d5410b/ghc" 19d5c73/ghc]: > {{{ > #!CommitTicketReference repository="ghc" revision="19d5c7312bf0ad9ae764168132aecf3696d5410b" > Add a CSE pass to Stg (#9291) > > ... > > Introduces the flag -fstg-cse, enabled by default with -O for now. It > might also be a good candidate for -O2. Will you revisit the `-O2` inclusion sometime later? /me was always under the impression that all performance-increasing optimisations from `-O` would be included in `-O2`. > > Differential Revision: https://phabricator.haskell.org/D2871 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:41:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:41:14 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.7d838940510c1463defcf329b150a36e@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:41:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:41:49 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.be99b03c41e44caa1214dc93bd13bbaa@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:44:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:44:01 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.12740ec73c779c6833514ec1ceb72803@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 Comment: Punting this as I've been too busy to finish the patch. But I now have worked out how I can solve the remaining issues so should be able to wrap it up for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:45:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:45:15 -0000 Subject: [GHC] #5620: Dynamic linking and threading does not work on Windows In-Reply-To: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> References: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> Message-ID: <061.b44b0a29fa0937956bce8a5f961363f9@haskell.org> #5620: Dynamic linking and threading does not work on Windows -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.2.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:45:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:45:33 -0000 Subject: [GHC] #12498: Support unconventionally named import libraries In-Reply-To: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> References: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> Message-ID: <059.5ef5b2a7eba84d29da704606b4800675@haskell.org> #12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:45:48 -0000 Subject: [GHC] #12499: Support multiple library import libs In-Reply-To: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> References: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> Message-ID: <059.aad8df80f6000c3d9f6c52d42fa51f5c@haskell.org> #12499: Support multiple library import libs -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:47:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:47:28 -0000 Subject: [GHC] #5291: GhcDynamic build fails on Windows: can't find DLLs In-Reply-To: <053.e4631d459b033afbd6e954b6e6b28a34@haskell.org> References: <053.e4631d459b033afbd6e954b6e6b28a34@haskell.org> Message-ID: <068.6f6e69c54980ed1f18b06d33a35bef5e@haskell.org> #5291: GhcDynamic build fails on Windows: can't find DLLs -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Build System | Version: 7.0.3 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-): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 14:49:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 14:49:51 -0000 Subject: [GHC] #13071: GHCi 8.0.1 panic with PatternSynonyms In-Reply-To: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> References: <045.e0a6258b92b1d308b5776dc14be66a96@haskell.org> Message-ID: <060.15794fcd0f6b2a67d06046993b66ba26@haskell.org> #13071: GHCi 8.0.1 panic with PatternSynonyms -------------------------------+---------------------------------------- Reporter: taktoa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: PatternSynonyms Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by RyanGlScott): I can confirm it's fixed in 8.0.2: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.1.20161213: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, modules loaded: Main. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:00:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:00:10 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.603d1adf6f3779c86df2cf728b577134@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @Phyx- Hi, Sorry for the lack of updates. Some parts of this are working, but in general my patches are not yet ready for inclusion in GHC and I haven't had time to work on them during the last six months. I do still want to finish this, but can't guarantee it will happen in time for 8.4. Anyone willing to help out is welcome to take a look at * https://github.com/23Skidoo/haskell-iocp and * https://github.com/23Skidoo/ghc/tree/ghc-8.0-windows-iocp and ask me any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:19:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:19:30 -0000 Subject: [GHC] #5344: CSE should look through coercions In-Reply-To: <046.337028ce6bbff67a50874240336d3596@haskell.org> References: <046.337028ce6bbff67a50874240336d3596@haskell.org> Message-ID: <061.1e78784025ed8de0cc306cb34a28b918@haskell.org> #5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: duplicate | Keywords: cse 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): Indeed it is easier as it can done by task. But I still believe type- changing CSE on the Core level is a research paper quality problem (and an interesting one!). We could keep this ticket open for that point in the design space, so if you want, feel free to reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:21:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:21:29 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.c3e20ee14d7e06488cfea6b1495f4fdf@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Will you revisit the -O2 inclusion sometime later? /me was always under the impression that all performance-increasing optimisations from -O would be included in -O2. Oh, of course it is in `-O2`! The question is whether it should only be in `-O`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:27:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:27:25 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.24cc7e2516a78b1fa8d8fd4abae89b53@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by ekmett): In response to Reid's prodding, I see two decisions to make here: 1.) There are ultimately 3 possible default implementations of `minimumBy`/`maximumBy` based on `foldl1`, `foldr1`, or `foldMap` respectively. 2.) We also need to decide whether we should add `maximumBy` and `minimumBy` to the class. `maximum` and `minimum` being in the class can improve the asymptotics of these operations. e.g. Set offers O(log n) `minimum` and `maximum` today, unlike before. Moreover, in the case of `minimum` and `maximum` 'a' is a fully knowable type for some containers, so they can even handle some infinite cases. Having them in the class also happened to also let us paper over the difference between the left fold and right fold in the old Foldable code for `maximum` and `minimum` for lists and fix the analogous space leak there. We didn't go with a right fold, but went with a monoidal fold instead as it was never asymptotically worse than the right fold we had in Foldable before. But here the situation is a bit different. Without more knowledge about the `b` type in the `(a -> b)` fitness function passed in there is no scenario in which a `foldr1`-based `maximumBy` can get early termination, so there is no real justification to the current implementation. It is leakier than a `foldl1` solution and never better! Even trying to argue there is some theoretical kind of snoclist container doesn't pan out, if our chosen semantics is to return the first value with the maximum value by fitness function, you'd have to reassociate all the way anyways. So at the very least there is no justification for a `foldr1` based solution. Ultimately, `maximumBy` and `minimumBy` are both operations that only make sense for finite containers. Here we're stuck touching all of the distinct members of the container at the least once as we don't know what fitness function the user will supply or any properties of the output type, to say, get early termination by reaching `minBound`/`maxBound`, or exploit properties of the type, like the laziness of "Lazy Nat" max. Adding `maximumBy`/`minimumBy` to the class would in theory allow a few obscure cases: The only real thing they can do is take advantage of the knowledge of which distinct 'a's they hold and send them through the scoring function individually without repetition. This would allow some containers to exploit a monoidal fold and pay proportional to the number of distinct values in the container rather than the total number of values. e.g. something like http://hackage.haskell.org/package/compressed-3.10/docs/Data-Compressed- LZ78.html could either just skim the tokens rather than do a full decompression, or use a monoidal fold to get most of that benefit in practice. If we have k distinct values, a monoidal fold version of `maximumBy` for some containers that tracked distinct values could get O(k) rather than O(n). Somewhat weaker, the `compressed` code above could pay proportional to the size of the compressed data set, not the full data set. Basing something on `foldMap` without the ability to redefine it in the class would effectively result in the bad `foldr`-style stack usage for lists. And frankly, it'd be nice to have a better story rather than 'lets favor monoidal implementations but hack in left folds for lists' pattern that seems to be cropping up over and over! Off the cuff, we could possibly address the root cause of this and a couple other issues by adding a `foldMap'` that uses a `foldl'` evaluation order on lists and strict monoidal accumulator and basing the (possibly default) definition of both `maximum` and `maximumBy` on that combinator. This appeals to me as it could serve to reduce pressure to add more members to the class of this sort, while avoiding more of these sorts of stack space regressions. I say "off the cuff" as I haven't had time to work through all the consequences of such a combinator. and it isn't the only design in this space, other designs in this space include making a single hideous Frankenstein combinator that takes multiple fold types worth of arguments and chooses an implementation accordingly, etc. A straw man solution would be to add `foldMap'` to the class, switch `maximum` and `maximumBy` to invoke it, and have it perform a monoidal fold in `foldl'` style either by default or just in the list case. As an embellishment on that design we could even add `sum'` and `product'` combinators that went through this path rather than randomly leak space. This would need some design work to work through consequences and implementation, but seems doable. **tl;dr** At the very least I agree that the current `foldr1` implementation of `maximumBy` and `minimumBy` is a mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:29:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:29:18 -0000 Subject: [GHC] #5344: CSE should look through coercions In-Reply-To: <046.337028ce6bbff67a50874240336d3596@haskell.org> References: <046.337028ce6bbff67a50874240336d3596@haskell.org> Message-ID: <061.bc3a8935cd699ea2f7de53559121e1a0@haskell.org> #5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: cse 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): * priority: normal => low * status: closed => new * resolution: duplicate => * owner: simonpj => Comment: OK, I think reopening (with milestone _|_) is appropriate then. Also setting priority to low in view of this case being handled by #9291; to be re-raised if someone comes up with a compelling reason to do the CSE earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:34:24 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.e98b33efc4e3849adb59d39a4dc45adc@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a much simpler program that also trips up the same error: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} module Bug (foo) where import Data.Kind (Type) foo :: forall (dk :: Type) (c :: Type -> Type) (t :: dk -> Type) (a :: Type). (dk ~ Type) => (forall (d :: dk). c (t d)) -> Maybe (c a) foo _ = Nothing }}} To make things more interesting, on GHC HEAD this errors with: {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161218 for x86_64-unknown-linux): tcTyVarDetails cobox_aCE :: (dk_aCl[sk:2] :: *) ~# (* :: *) 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/basicTypes/Var.hs:461:22 in ghc:Var }}} But on GHC 8.0.1 and 8.0.2, it compiles fine! So this is actually a regression. I don't know if heisenbug's patch fixes it, nor what commit caused this regression. I'll look later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:39:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:39:24 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.f08419f9822eb5cd8fa8a5101aaa89a2@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm happy with any resolution under which `maximumBy` on a `[a]` is defined in terms of `foldl1` (presuming that, as a result, strictness analysis can remove the space leak for `maximumBy` on a `[Int]`, as was the case in GHC 7.8). I didn't really mean to push for the "add a new method to `Foldable`" solution specifically. (That was motivated by maintaining the old behavior for other `Foldable` instances as far as possible, but if the old behavior is actually useless then that motivation doesn't apply.) If there's a minimal change that we could apply now to obtain the above condition, while leaving the door open to future extensions, I'd be in favor of making the minimal change now, since the current situation with `maximumBy` on lists is really not very good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:43:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:43:43 -0000 Subject: [GHC] #13072: Move large tuples to a separate module in base Message-ID: <047.4df951c2bddac1813610b08eef5bf762@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.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: -------------------------------------+------------------------------------- Quoting from my message to ghc-devs@: > It occurred to me that rather than moving just these instances to a new module, we could move the large tuples themselves to a new module Data.LargeTuple and put the instances there. The Prelude would reexport the large tuples, so there would be no user-visible change. According to my experiments, GHC should never have to read the Data.LargeTuple interface file unless a program actually mentions a large tuple type, which is presumably rare. We could then also extend the existing instances for Eq, Show, etc., which are currently only provided through 15-tuples. > > A nontrivial aspect of this change is that tuples are wired-in types, and they currently all live in the ghc-prim package. I'm actually not sure why they need to be wired-in rather than ordinary types with a funny- looking name. In any case I need to look into this further, but the difficulties here don't seem to be insurmountable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:47:26 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.9dba52987403634a35b13bbf5ed20ef8@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Looking at the tests, I do not see `Either x y <-> Maybe y` coercions. Are these supposed to be done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:50:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:50:22 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.ef426d157a4653f9bb4e5a6d99ad3dc4@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Looking at the tests, I do not see Either x y <-> Maybe y coercions. Are these supposed to be done? Are you referring to treating a `Just x` directly `Right x`, i.e. using similarly looking constructors at a different type? That is not included here, and it is not clear whether we actually want it done. If you think we do, please open a new ticket for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:51:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:51:03 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.63bf8dfbfcf29fab3cec06e437df8728@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by geraint): Running otool only tells me about libHSinteger-gmp, specifically: @rpath/libHSinteger-gmp-1.0.0.1-ghc8.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) but I edited an earlier comment (which apparently doesn't generate an email): "... by dint of looking at HsIntegerGmp.h I see it is 5.0.4 and GHC_GMP_INTREE is true, so it is the presumably the allocation bug in gmp." This is how it comes for the Mac in the current Haskell platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 15:55:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 15:55:36 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.fa336a65e1eddc791245c138e01a714c@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:47 nomeata]: > > Looking at the tests, I do not see Either x y <-> Maybe y coercions. Are these supposed to be done? > > Are you referring to treating a `Just x` directly `Right x`, i.e. using similarly looking constructors at a different type? That is not included here, and it is not clear whether we actually want it done. If you think we do, please open a new ticket for it. Yes, that is what I mean. They would be memory-layout compatible. I'll ponder a bit more, and if I still think it's a good idea, I'll follow up with a ticket. Thanks for doing this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 16:05:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 16:05:00 -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.c56ac63263fc030ddf23acedf3de0a1e@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * priority: normal => high * status: infoneeded => new * milestone: => 8.2.1 Comment: This is still applicable and was reported again as #12954. I don't understand why we can't just update the in-tree GMP version; hvr, can you elaborate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 16:05:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 16:05:15 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.0535ac4ccf23fd82e2a97b12418364a3@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by rwbarton): * status: infoneeded => new Comment: Aha, I missed the part about `GHC_GMP_INTREE` being true. Then yes, I'll close this as a duplicate of #7655. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 16:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 16:05:28 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.a40fb49c1156e3be0286f9d3fb397636@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #7655 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #7655 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 17:21:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 17:21:57 -0000 Subject: [GHC] #13069: hs-boot files permit default methods in type class In-Reply-To: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> References: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> Message-ID: <060.f8dfc6114fc5489e409eaeb776c4bb1f@haskell.org> #13069: hs-boot files permit default methods in type class -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): It looks like some hs-boot files have come to rely on this behavior: {{{ MiniAgda-0.2014.9.12/Eval.hs-boot:class Reval a where MiniAgda-0.2014.9.12/Eval.hs-boot- reval' :: Valuation -> a -> TypeCheck a MiniAgda-0.2014.9.12/Eval.hs-boot- reval :: a -> TypeCheck a MiniAgda-0.2014.9.12/Eval.hs-boot- reval = reval' emptyVal postgresql-simple-0.5.2.1/src/Database/PostgreSQL/Simple/ToRow.hs- boot:class ToRow a where postgresql-simple-0.5.2.1/src/Database/PostgreSQL/Simple/ToRow.hs-boot- toRow :: a -> [Action] postgresql-simple-0.5.2.1/src/Database/PostgreSQL/Simple/ToRow.hs-boot- default toRow :: (Generic a, GToRow (Rep a)) => a -> [Action] postgresql-simple-0.5.2.1/src/Database/PostgreSQL/Simple/ToRow.hs-boot- toRow = gtoRow . from event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot:class (MonadEvent m e, MonadTime m t) => ScheduleEvent m t e | m -> t event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot- where event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot- scheduleEventAt :: t -> e -> m EventID event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot- doNext :: e -> m () event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot- doNext e = do event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot- now <- getCurrentTime event-monad-0.0.3/src/Control/Monad/Event/Classes.hs-boot- scheduleEventAt now e }}} Maybe less than a dozen I could see on Hackage. So maybe we should just update the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 17:45:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 17:45:49 -0000 Subject: [GHC] #13069: hs-boot files permit default methods in type class In-Reply-To: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> References: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> Message-ID: <060.1a8a0734f14c8df946a4a42699d6808e@haskell.org> #13069: hs-boot files permit default methods in type class -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Actually, the bug is worse: the following A.hs-boot file is accepted by GHC. {{{ module A where class C a where f :: a -> a f = True }}} This doesn't seem to be a soundness problem because what this actually seems to translate into "there is a default method for f", so this code never gets compiled / used for anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 17:46:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 17:46:32 -0000 Subject: [GHC] #13069: hs-boot files permit default methods in type class (but don't typecheck them) (was: hs-boot files permit default methods in type class) In-Reply-To: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> References: <045.b0afcf989adf5374477a1a8a1d5c64e2@haskell.org> Message-ID: <060.0219d8e8d9b53c0735ae3bcad59113ee@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: 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 17:47:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 17:47:12 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.8f0dcec888bf3d92d99ae39dff5b1139@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 simonpj): I think that's a reasonable point. If you follow it up, could you include a Note to explain the reasoning? And refer to the Note from the relevant INLINE pragmas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:18:47 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.2940813ef296b8c3205219a7f942027a@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Nor will this happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:21:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:21:45 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.9e47e0baef2465cac95b3ed27a1b39a3@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: upstream Priority: high | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * priority: normal => high * status: new => upstream Comment: This is waiting on a the `process` PR mentioned in comment:7. Bumping in priority since I would really like to have Windows finally stable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:23:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:23:37 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.fdf737247c1f72dd26cdf915ee856b40@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari 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: goldfire => bgamari Comment: Given that I'm working on `Typeable` for 8.2 I'll take ownership of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:26:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:26:02 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.c3405c6a636f3fd5a0ce40e21dbd3f13@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: upstream Priority: high | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): I currently have a new version of the pull request, just need to finish testing. I also committed a workaround for this in the testsuite. The error seems to not change the exit code as it seems to be mostly informational. Also the work seems to be done it's just cleaning up that fails. So I had the testsuite just strip this message out if it's found. The test runs shouldn't be reporting this anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:29:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:29:55 -0000 Subject: [GHC] #11096: Builtin encoder/decoder should be used for Latin-1 In-Reply-To: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> References: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> Message-ID: <061.349d69eeb1719241d574dd98587b00fa@haskell.org> #11096: Builtin encoder/decoder should be used for Latin-1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Ahh, this is actually fixed. Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:34:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:34:03 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.02bc3d32f7bae3a689ee9c229b3cce98@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: 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): harendra, do you think you will be able to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 19:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 19:34:53 -0000 Subject: [GHC] #12426: Allow smart constructors their own types In-Reply-To: <045.935c148fda32feaf05d8d4eda84c7495@haskell.org> References: <045.935c148fda32feaf05d8d4eda84c7495@haskell.org> Message-ID: <060.6d5ea0b9a9b75d6d9a18cd5319764c65@haskell.org> #12426: Allow smart constructors their own types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8581 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Let's mark it as a duplicate in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 20:22:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 20:22:17 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.9cb2e9b6f89344830f5d8c9099110fa2@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by ekmett): I'm okay with switching `maximumBy` and `minimumBy` to `foldl1` for now. This would at least fix the stack space regression relative to the original `[]` implementation. It'd be a big step in the right direction from the status quo. If ''later on'' we can come up with a `foldMap'` or similar alternative with palatable semantics we can switch over to that and we should be able to retain the stack benefits. This would buy us time to fiddle with the semantics and implementation of such a combinator and see how well it can optimize. Breaking up the fix like this would avoid letting the quest for the perfect solution derail us from fixing an annoying regression in a common combinator today, and even if the second stage never happened this path would still make most consumers happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 20:47:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 20:47:24 -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.47813aec577b15060c4bf5d2a8dc1681@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:14:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:14:56 -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.5c9dd8c02b1fb2fa28b92091d6cb678d@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => dfeuer Comment: David is currently looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:15:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:15:47 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.4583a16feda9394e0e18612756b4987a@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Let me try. I will need a reviewer. I guess all we need to do for now is - add deprecation warnings for what is to be removed in future and remove it from the documentation. The deprecation warnings will show on stderr. Later, at some point in time we will remove the unsupported ways/flags of invoking runghc. Does that sound good? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:26:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:26:53 -0000 Subject: [GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference In-Reply-To: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> References: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> Message-ID: <062.bd633a32ac1d3805992c2b7a6c91ca0d@haskell.org> #9248: Document -XHaskell98 and -XHaskell2010 in flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #1880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: goldfire, did you mean to claim ownership of this? Either way it sadly seems this won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:30:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:30:25 -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.d844712b68b4753499fd89c0021cfeec@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: feature request | Status: new Priority: high | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Bumping priority of this since the Typeable rework is contingent on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:31:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:31:36 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.1fa6e7b514655ea859d016fe84d36457@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: > Oh dear. Which ways? What errors? Unfortunately it doesn't happen very often; I'll try to paste some output here next time I see this rear its ugly head. Bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:32:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:32:33 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.77992351da60ce5bc0daed5ba7586a35@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It seems unlikely that this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:34:24 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.5087a566751a4a0a6d34cf2a349b1277@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I don't think this will happen for 8.2 though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 21:36:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 21:36:56 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.ebac25916f43d6e32abee9a1188a5a0e@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: 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): > Let me try. I will need a reviewer. I guess all we need to do for now is - add deprecation warnings for what is to be removed in future and remove it from the documentation. The deprecation warnings will show on stderr. Later, at some point in time we will remove the unsupported ways/flags of invoking runghc. Sounds reasonable to me. I'll gladly review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 22:01:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 22:01:36 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.2ac1650cc5f68f7f2d502f07e3391178@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5ef956e137b35cd53dba3db2f475e97d442b1ba9/ghc" 5ef956e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5ef956e137b35cd53dba3db2f475e97d442b1ba9" Fix doctests in Data.Functor Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2920 GHC Trac Issues: #11551 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 22:01:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 22:01:36 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.6fa58901acd4a6ff09dd7a69f8634c56@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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:D2916 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5f91ac89a38eb128d374a04c741bbd81c41fed37/ghc" 5f91ac8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f91ac89a38eb128d374a04c741bbd81c41fed37" Coerce for fmapDefault and foldMapDefault Define `fmapDefault = coerce traverse` and `foldMapDefault = coerce traverse`. This ensures that we won't get unnecessary allocation and indirection when the arguments don't inline. Fixes #13058 Reviewers: ekmett, RyanGlScott, austin, hvr, bgamari Reviewed By: RyanGlScott Subscribers: simonpj, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D2916 GHC Trac Issues: #13058 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 22:05:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 22:05:39 -0000 Subject: [GHC] #13073: BooleanFormula implies is wrong Message-ID: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> #13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current implementation looks like this: {{{ implies :: Eq a => BooleanFormula a -> BooleanFormula a -> Bool x `implies` Var y = x `impliesAtom` y x `implies` And ys = all (implies x . unLoc) ys x `implies` Or ys = any (implies x . unLoc) ys x `implies` Parens y = x `implies` (unLoc y) }}} This cannot possibly be correct: this will decompose the formula A \/ B -> A \/ B in the following way {{{ Or [Var a, Var b] `implies` Or [Var a, Var b] Or [Var a, Var b] `implies` Var a || Or [Var a, Var b] `implies` Var b }}} But neither of the decomposed formulas are true. I didn't find a case in the typechecker where this actually mattered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 22:08:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 22:08:50 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.cecdf4c87c85ee1b582138ba11960de6@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: That patch did fix building the program in comment:7, FWIW. Also, I found out that Simon's commit a0899b2f66a4102a7cf21569889381446ce63833 caused the regression: {{{ From a0899b2f66a4102a7cf21569889381446ce63833 Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Tue, 1 Mar 2016 17:05:56 +0000 Subject: [PATCH] Remove unnecessary isTyVar tests in TcType These extra tests were added by Richard when he had CoVars floating around in places where previously only TyVars had been. But fortunately those days are gone, so these tests are unnecessary, and are slowing GHC down. Let's remove them. }}} It looks like Simon has [https://ghc.haskell.org/trac/ghc/changeset/f4a14d6c535bdf52b19f441fe185ea13d62fdc24/ghc done some digging] on this recently, but I'll cc him just in case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 5 22:53:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jan 2017 22:53:31 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.9e36356317daf5b00ac656df169628de@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here's one example, {{{ +++ "/tmp/ghctest-8lrukibe/test spaces/./concurrent/should_run/setnumcapabilities001.run/setnumcapabilities001.run.stderr.normalised" 2017-01-05 17:29:54.673595299 -0500 @@ -0,0 +1 @@ +setnumcapabilities001: sendWakeup: invalid argument (Bad file descriptor) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 01:23:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 01:23:26 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.6b1b5deabc646ec0b9dbbd9ba34c6428@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've left the test running for several thousand iterations in the background and have seen the error mentioned in comment:9 pop up a handful of times. On the bright side, this appears to be the only failure mode. It seems what is happening here is that the IO manager is trying to wake- up a manager thread which has already exited. We could simply add an `IORef` to `Control` to indicate that the manager has exited, but it's not clear to me whether this would merely be working around some more sinister root cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 01:31:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 01:31:16 -0000 Subject: [GHC] #13058: Use coercions to implement fmapDefault and foldMapDefault In-Reply-To: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> References: <045.ab31ef46bed96cf28dc205531dc12c7b@haskell.org> Message-ID: <060.a7d36c6573a4046b91b26dd3c080f444@haskell.org> #13058: Use coercions to implement fmapDefault and foldMapDefault -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | 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:D2916 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 01:33:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 01:33:52 -0000 Subject: [GHC] #13041: Type classes in Backpack signatures are dodgy In-Reply-To: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> References: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> Message-ID: <060.d7f63af350e1a4277bebd8cb90a5eb4e@haskell.org> #13041: Type classes in Backpack signatures are dodgy -------------------------------------+------------------------------------- Reporter: ezyang | 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:2925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:2925 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 03:45:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 03:45:02 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.3b17568fbcc63d8289caa59c123f25e4@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I scattered a few `HasCallStacks` about and let it run again and saw the following failure, {{{ setnumcapabilities001: sendWakeup CallStack (from HasCallStack): sendWakeup, called at libraries/base/GHC/Event/TimerManager.hs:205:19 in base:GHC.Event.TimerManager wakeManager, called at libraries/base/GHC/Event/TimerManager.hs:223:7 in base:GHC.Event.TimerManager registerTimeout, called at libraries/base/GHC/Event/Thread.hs:59:10 in base:GHC.Event.Thread: invalid argument (Bad file descriptor) }}} The last frame of the callstack corresponds to the `registerTimeout` in `threadDelay`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 05:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 05:08:08 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.20146e5693edd811563be6e8e24095f1@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2926 Comment: Phab:D2926 is a somewhat questionable patch I put together between builds. I'm a bit unsure as to whether the approach is the sort of thing we want, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 07:40:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 07:40:19 -0000 Subject: [GHC] #13074: Printing ~ Message-ID: <052.03db17d10626c755958600c52933cbfc@haskell.org> #13074: Printing ~ -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: 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: -------------------------------------+------------------------------------- {{{#! class Relation (r :: x -> x -> Type) instance Relation (~) }}} /home/samuel/Work/research/program/relations/src/Hmm.hs:35:19: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): print_equality ~ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This clearly isn't a terribly important bug, but I figured I'd leave it here as that was the request given by the error message. It's not code that should compile, but it shouldn't panic!. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 10:52:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 10:52:41 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.c8feffe3fd86667bf22a62acce33f47e@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | 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:"3540d1e1a23926ce0a8a6ae83a36f5f6b2497ccf/ghc" 3540d1e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3540d1e1a23926ce0a8a6ae83a36f5f6b2497ccf" Avoid exponential blowup in FamInstEnv.normaliseType Trac #13035 showed up a nasty case where we took exponentially long to normalise a (actually rather simple) type. Fortunately it was easy to fix: see Note [Normalisation and type synonyms]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 10:52:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 10:52:41 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.93063e43835402e8483bea5a322583a7@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T13025 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b4f2afe70ddbd0576b4eba3f82ba1ddc52e9b3bd/ghc" b4f2afe7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b4f2afe70ddbd0576b4eba3f82ba1ddc52e9b3bd" Fix the implementation of the "push rules" Richard pointed out (comment:12 of Trac #13025) that my implementation of the coercion "push rules", newly added in exprIsConAppMaybe by commit b4c3a66, wasn't quite right. But in fact that means that the implementation of those same rules in Simplify.simplCast was wrong too. Hence this commit: * Refactor the push rules so they are implemented in just one place (CoreSubst.pushCoArgs, pushCoTyArg, pushCoValArg) The code in Simplify gets simpler, which is nice. * Fix the bug that Richard pointed out (to do with hetero-kinded coercions) Then compiler performance worsened, which led mt do discover two performance bugs: * The smart constructor Coercion.mkNthCo didn't have a case for ForAllCos, which meant we stupidly build a complicated coercion where a simple one would do * In OptCoercion there was one place where we used CoherenceCo (the data constructor) rather than mkCoherenceCo (the smart constructor), which meant that the the stupid complicated coercion wasn't optimised away For reasons I don't fully understand, T5321Fun did 2% less compiler allocation after all this, which is good. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 10:55:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 10:55:28 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.313be73928e37309aafa92320931f1c4@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: 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: None/Unknown | Test Case: | perf/compiler/T13035 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => perf/compiler/T13035 * milestone: => 8.0.3 Comment: Thanks for a great report. It compiles in a flash now. Merge to 8.0.3 if convenient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 10:56:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 10:56:42 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.2c23d96b48b6e0381aa6431abef00b10@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T13025 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I fixed comment:13. Well spotted Richard! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 13:10:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 13:10:10 -0000 Subject: [GHC] #13073: BooleanFormula implies is wrong In-Reply-To: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> References: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> Message-ID: <060.f4599cd7abdacdd86937ade5f8bd5d92@haskell.org> #13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I am fairly sure the only place where `BooleanFormula` is used is `MINIMAL` pragmas but I assume you were trying to use it for something else if you found this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 13:28:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 13:28:04 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.d7b51390cac77b1b69834d14d26d0f01@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): e6aefd6e07ef04d068d727490c640c68c82e4954 is another fix There are still about 40 occurrences of unchecked functions in the GHC sources. Tackling one of them should be a nice well-scoped GHC starter task. The main difficulty is not introducing unnecessary performance regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 13:38:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 13:38:15 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.c499df4aba4a03f5c936c40e5d584264@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | 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:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I figured this one. GHC propagates strictness information from 'error' to 'makeStatic', and then from 'makeStatic' to the floated top-level binding which uses it. The only effective way I found to turned it off is to use {{{ {-# OPTIONS_GHC -fignore-interface-pragmas #-} }}} at the top of {{{GHC/StaticPtr/Internal.hs}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 13:41:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 13:41:47 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.f26d93e272f1103231c41703b72da8c9@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => closed * resolution: => fixed Comment: I think we've done all we could here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 13:57:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 13:57:25 -0000 Subject: [GHC] #13074: Printing ~ In-Reply-To: <052.03db17d10626c755958600c52933cbfc@haskell.org> References: <052.03db17d10626c755958600c52933cbfc@haskell.org> Message-ID: <067.7dd9311a92f0e2e9097431cc4cd18321@haskell.org> #13074: Printing ~ -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: closed Priority: low | 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 goldfire): * status: new => closed * resolution: => duplicate Comment: Many thanks for reporting, but this has already been fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:19:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:19:24 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.f02aab4b9ba5c70397ed53bfa47903c3@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | 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): Ah, good to know, but mwc-random isn't a nofib program, even though it sounds like it could be. It's a package on hackage for generating random numbers. (You may be thinking of the k-nucleotide issue, which is a nofib program.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:28:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:28:54 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.857aba9d3c1adae60224667b2541ef3e@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While comment:10 is indeed an odd interaction, these sorts of problems become inevitable. I'm reminded of a scene in the movie Interstellar where a robot describes that his "honesty setting" is at 90%, because that just works out better than being 100% honest. As GHC's type system has become more complicated, users have been requesting it to lower its honesty setting, hiding bits and pieces that look scary. We now have `-fprint- explicit-kinds`, `-fprint-explicit-coercions`, `-fprint-explicit-foralls`, `-fprint-equality-relations`, and `-fprint-explicit-runtime-reps`. Each of these flags are off by default, and each one is essentially an honesty setting. Perhaps with the exception of `-fprint-explicit-coercions`, the fact that GHC lies about these aspects of a program means that programmers may make mistakes -- it's the old "garbage in, garbage out", but in reverse! (with the humans getting and producing the garbage) I don't know how to really solve this, short of #8809, which would lead to Idris-like interactivity in error messages. We could try to figure out when a user has produced garbage in response to a lie that GHC has told and then tell the user to tell GHC not to lie (as we do when we suggest `-fprint-explicit-kinds` in error messages), but I think we'll always be playing catch-up. Instead, we should give the user the direct option (via #8809) to know when GHC is lying and to request the truth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:36:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:36:59 -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.e07a435430167163591332af93bbee50@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | 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 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"508811004d1806b28a91c3ff4a5c2247e2ad4655/ghc" 5088110/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="508811004d1806b28a91c3ff4a5c2247e2ad4655" Add performance test for #13056 This performance regression was fixed by commit 517d03e41b4f5c144d1ad684539340421be2be2a (#12234). Let's add a performance test to ensure that it doesn't break again. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:36:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:36:59 -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.18f2448981722f6f09c3e70df48e9f72@haskell.org> #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"508811004d1806b28a91c3ff4a5c2247e2ad4655/ghc" 5088110/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="508811004d1806b28a91c3ff4a5c2247e2ad4655" Add performance test for #13056 This performance regression was fixed by commit 517d03e41b4f5c144d1ad684539340421be2be2a (#12234). Let's add a performance test to ensure that it doesn't break again. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:38:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:38:30 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.9299754b804715c1e3217b26c2c33c19@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): To respond to an earlier point that Reid and others have made. The potential problems with this pragma only highlight design compromises with pattern synonyms. The specific issue being that pattern synonyms are ad- hoc collections rather than a complete set of covering patterns. Reid's suggestion of improving exhaustiveness checking by seeing if the view function is injective is akin to suggesting that one should only be allowed to define complete sets of pattern synonyms in the first place. I see the design I have implemented as the sensible way of doing so. If we forced all users to write pattern synonyms in the way that Reid described then we would have been better off implementing views! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:38:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:38:38 -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.6b92a4e8bae0d68811bf296a14641e0b@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: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12234 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * milestone: => 8.0.3 Comment: This can be merged alongside #12234. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 14:54:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 14:54:28 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted Message-ID: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: -------------------------------------+------------------------------------- When I compile/link {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where !(Just x) = Nothing main = putStrLn "hi there!" }}} I get {{{ rae:09:50:49 ~/temp> ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... ld: can't open output file for writing: Bug, errno=21 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) }}} This bogus code should be rejected more gracefully (and earlier). It actually also loads into GHCi, but shouldn't. Will fix while I'm in the area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 15:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 15:03:35 -0000 Subject: [GHC] #12953: Use computed gotos in the interpreter when the compiler supports it In-Reply-To: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> References: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> Message-ID: <062.163fb95ef089c038b0e8e7a71a785f8a@haskell.org> #12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: interpreter Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This was discussed in `#ghc` and the fact that OCaml's [https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c|interpreter] does this came up. The implementation really doesn't seem too invasive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 15:36:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 15:36:50 -0000 Subject: [GHC] #12896: Consider using compact regions in GHC itself to reduce GC overhead In-Reply-To: <047.4913bc95579abdcd37d52f2b35894734@haskell.org> References: <047.4913bc95579abdcd37d52f2b35894734@haskell.org> Message-ID: <062.dafc27c05c1ed40d82e21684ad2aee12@haskell.org> #12896: Consider using compact regions in GHC itself to reduce GC overhead -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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 niteria): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 15:52:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 15:52:12 -0000 Subject: [GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger Message-ID: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: #13076: GHC panics can cause text-formatting changes from colorized error messages to linger + Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8809, #12785 Differential Rev(s): | Wiki Page: + This bug relies on GHC panicking right after emitting a normal error message, so take note that I reproduced this error using a GHC HEAD build at commit 508811004d1806b28a91c3ff4a5c2247e2ad4655, and if #12785 is fixed, then this won't be reproducible anymore. If I compile this program from #12785: [...] Content analysis details: (7.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 1.2 MISSING_HEADERS Missing To: header 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language -------------- next part -------------- An embedded message was scrubbed... From: "GHC" Subject: [GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger Date: Fri, 06 Jan 2017 15:52:12 -0000 Size: 4690 URL: From ghc-devs at haskell.org Fri Jan 6 15:53:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 15:53:51 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.907cb2375921f1ca7409c99ddab84f5b@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"3a18baff06abc193569b1b76358da26375b3c8d6/ghc" 3a18baf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3a18baff06abc193569b1b76358da26375b3c8d6" More fixes for #5654 * In stg_ap_0_fast, if we're evaluating a thunk, the thunk might evaluate to a function in which case we may have to adjust its CCS. * The interpreter has its own implementation of stg_ap_0_fast, so we have to do the same shenanigans with creating empty PAPs and copying PAPs there. * GHCi creates Cost Centres as children of CCS_MAIN, which enterFunCCS() wrongly assumed to imply that they were CAFs. Now we use the is_caf flag for this, which we have to correctly initialise when we create a Cost Centre in GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 16:07:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 16:07:32 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.7d57a78a0021a87bb7b65284710d4a57@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://www.reddit.com/r/haskell/comments/5me65b/is_haskells_sequence_safe/ Strikes again]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 16:10:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 16:10:53 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.54e43905f8ba2a8c831ea35adb9a4a2b@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | 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:D2709 Wiki Page: | Phab:D2720 Phab:D2930 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: Phab:D2709 Phab:D2720 => Phab:D2709 Phab:D2720 Phab:D2930 Comment: I just submitted the implementation to phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 16:25:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 16:25:19 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.eed323b123f598d0ddc5fda1365d1bb2@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Phab:D2931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D2931 Comment: I tried poking around the code from a0899b2f66a4102a7cf21569889381446ce63833. Interestingly, adding back the explicit `isTyVar` check to `isFloatedTouchableMetaTyVar` fixes the program in comment:7, but //not// heisenbug's program. I could try to hunt for the other function that trips up heisenbug's program, but chances are there other undiscovered programs that would trip up this panic through other means. Therefore, to minimize the chances of that happening, I've opted to open Phab:D2931, which simply reverts a0899b2f66a4102a7cf21569889381446ce63833. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 16:31:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 16:31:33 -0000 Subject: [GHC] #12896: Consider using compact regions in GHC itself to reduce GC overhead In-Reply-To: <047.4913bc95579abdcd37d52f2b35894734@haskell.org> References: <047.4913bc95579abdcd37d52f2b35894734@haskell.org> Message-ID: <062.29ff9e023bd40ea6b70382a07c2626e6@haskell.org> #12896: Consider using compact regions in GHC itself to reduce GC overhead -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by simonmar): I actually tried using it for interface files, but it won't work (yet). We can't compact pinned memory, and FastString is implemented in terms of ByteString, which is backed by pinned memory. Perhaps we ought to special-case this somehow, because compacting things involving ByteString would be really useful - it would be possible but we have to adjust the address stored in the ByteString when we copy it. (or fix ByteString to use unpinned memory, which we want to do anyway, but that's harder). Also I'm not 100% sure that there aren't functions buried somewhere in ModIface, which also can't be compacted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:07:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:07:50 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.e41096cdb8a8ed741d6041520ed6311e@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 carter): https://phabricator.haskell.org/D2929 resolves this or potentially does? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:08:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:08:57 -0000 Subject: [GHC] #13073: BooleanFormula implies is wrong In-Reply-To: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> References: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> Message-ID: <060.9967108efdc6666cd11a2f5212abc470@haskell.org> #13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2925 Comment: Yes, implies is never used, only impliesAtom which seems to be implemented correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:15:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:15:33 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.5ed46a6d9c26943882fdc18eb1a459ba@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Facundo Domínguez ): In [changeset:"e5d1ed9c8910839e109da59820ca793642961284/ghc" e5d1ed9c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5d1ed9c8910839e109da59820ca793642961284" Have addModFinalizer expose the local type environment. Summary: Kind inference in ghci was interfered when renaming of type splices introduced the HsSpliced data constructor. This patch has kind inference skip over it. Test Plan: ./validate Reviewers: simonpj, rrnewton, austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie, mboes Differential Revision: https://phabricator.haskell.org/D2886 GHC Trac Issues: #12985 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:30:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:30:29 -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.28548c1e047f0f86e6cd44db29db16f1@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => perf/compiler/T13056 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:38:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:38:23 -0000 Subject: [GHC] #13077: Worker/wrapper can break the let-app invariant Message-ID: <046.dd2b4321fc316e147387f0f8a9549c64@haskell.org> #13077: Worker/wrapper can break the let-app invariant -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider this {{{ {-# LANGUAGE MagicHash #-} module Bar where import GHC.Exts data X = A | B | C data T = MkT !X Int# Int# f (MkT x 0# _) = True f (MkT x n _) = let v = case x of A -> 1# B -> 2# C -> n in f (MkT x v v) }}} Compile with -O and (with GHC 8) you'll get {{{ *** Core Lint errors : in result of Simplifier *** Bar.hs:10:23: Warning: [RHS of v_s1IX :: Int#] The type of this binder is primitive: v_s1IX Binder's type: Int# *** Offending Program *** Rec { f [InlPrag=INLINE[0]] :: T -> Bool [LclIdX, Arity=1, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (w_s1Jq [Occ=Once!] :: T) -> case w_s1Jq of _ [Occ=Dead] { MkT ww_s1Jt [Occ=Once] ww_s1Ju [Occ=Once] _ [Occ=Dead] -> $wf_s1Jx ww_s1Jt ww_s1Ju }}] f = \ (w_s1Jq :: T) -> case w_s1Jq of _ [Occ=Dead] { MkT ww_s1Jt ww_s1Ju ww_s1Jv -> $wf_s1Jx ww_s1Jt ww_s1Ju } $wf_s1Jx [InlPrag=[0], Occ=LoopBreaker] :: X -> Int# -> Bool [LclId, Arity=2, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [40 30] 80 10}] $wf_s1Jx = \ (ww_s1Jt :: X) (ww_s1Ju :: Int#) -> case ww_s1Ju of ds_X1IO [Dmd=] { __DEFAULT -> let { v_s1IX [Dmd=] :: Int# [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] v_s1IX = case ww_s1Jt of _ [Occ=Dead, Dmd=] { A -> 1; B -> 2; C -> ds_X1IO } } in $wf_s1Jx ww_s1Jt v_s1IX; 0 -> True } end Rec } }}} Reason: in the worker, the lambda-bound arguments don't say they are evaluated, so the previously ok-for-speculation RHS of the 'let' is no longer so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:50:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:50:35 -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.6362721fc352270315339b3cd3e9eb88@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): So I have a branch for this that builds successfully. However if I add instances to `GHC.LargeTuple`, then the instances aren't visible automatically. Using `:i` brings the instances into scope somehow. A sample ghci session: {{{ Prelude> let x = (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1) in x == x :3:46: error: • Ambiguous type variable ‘p0’ arising from a use of ‘x’ prevents the constraint ‘(Num p0)’ from being solved. Probable fix: use a type annotation to specify what ‘p0’ should be. These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others (use -fprint-potential-instances to see them all) • In the first argument of ‘(==)’, namely ‘x’ In the expression: x == x In the expression: let x = (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) in x == x :3:46: error: • No instance for (Eq (a0, b0, c0, d0, e0, f0, g0, h0, i0, j0, k0, l0, m0, n0, o0, p0)) arising from a use of ‘==’ • In the expression: x == x In the expression: let x = (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) in x == x In an equation for ‘it’: it = let x = ... in x == x Prelude> :i (,,,,,,,,,,,,,,,) data (,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p = (,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p -- Defined in ‘GHC.LargeTuple’ instance [safe] (Bounded p, Bounded o, Bounded n, Bounded m, Bounded l, Bounded k, Bounded j, Bounded i, Bounded h, Bounded g, Bounded f, Bounded e, Bounded d, Bounded c, Bounded b, Bounded a) => Bounded (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p) -- Defined in ‘GHC.LargeTuple’ instance [safe] (Eq p, Eq o, Eq n, Eq m, Eq l, Eq k, Eq j, Eq i, Eq h, Eq g, Eq f, Eq e, Eq d, Eq c, Eq b, Eq a) => Eq (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p) -- Defined in ‘GHC.LargeTuple’ instance [safe] (Ord p, Ord o, Ord n, Ord m, Ord l, Ord k, Ord j, Ord i, Ord h, Ord g, Ord f, Ord e, Ord d, Ord c, Ord b, Ord a) => Ord (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p) -- Defined in ‘GHC.LargeTuple’ Prelude> let x = (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1) in x == x True }}} Simon, do I need to apply a similar refactoring as you did in ffc21506894c7887d3620423aaf86bc6113a1071 ("Refactor tuple constraints")? I see `ConstraintTuple` is treated differently in `tcTupleTyCon`, which looks relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:52:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:52:57 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling Message-ID: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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: -------------------------------------+------------------------------------- When building 3a18baff06abc193569b1b76358da26375b3c8d6 with profiling, GHC emits this error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): kindPrimRep.go k0 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/simplStg/RepType.hs:369:9 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have attached my `build.mk` file. It may be wrong, but I don't think it includes anything that should break GHC. Even if it did, I should get some sort of error message, not a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:53:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:53:36 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling In-Reply-To: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> References: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> Message-ID: <062.d8bc8e0c19c9e15ef678ca8d1caa2fa1@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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 dobenour): * Attachment "build.mk" added. My build.mk file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:56:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:56:28 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling In-Reply-To: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> References: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> Message-ID: <062.e430053c8146fd53be199e59d18af32c@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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 dobenour: @@ -19,0 +19,3 @@ + + compiler/ghc.mk:582: recipe for target + 'compiler/stage2/build/StgCmmMonad.p_o' failed New description: When building 3a18baff06abc193569b1b76358da26375b3c8d6 with profiling, GHC emits this error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): kindPrimRep.go k0 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/simplStg/RepType.hs:369:9 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 }}} I have attached my `build.mk` file. It may be wrong, but I don't think it includes anything that should break GHC. Even if it did, I should get some sort of error message, not a panic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 17:57:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 17:57:17 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling In-Reply-To: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> References: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> Message-ID: <062.1178a1ec9c515c18f87a70fe7a32bd82@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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 dobenour: @@ -27,0 +27,3 @@ + + The bootstrap compiler is GHC 8.0.1, built from the `ghc-8.0.1-release` + tag in the Git repository. New description: When building 3a18baff06abc193569b1b76358da26375b3c8d6 with profiling, GHC emits this error: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170106 for x86_64-unknown-linux): kindPrimRep.go k0 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/simplStg/RepType.hs:369:9 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 }}} I have attached my `build.mk` file. It may be wrong, but I don't think it includes anything that should break GHC. Even if it did, I should get some sort of error message, not a panic. The bootstrap compiler is GHC 8.0.1, built from the `ghc-8.0.1-release` tag in the Git repository. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:19:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:19:15 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.58485b0e34c918aba222a6c88b0f5f5b@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Facundo Domínguez ): In [changeset:"c1ed9557ad4e40caa72b27693527e02887ddd896/ghc" c1ed9557/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1ed9557ad4e40caa72b27693527e02887ddd896" Have addModFinalizer expose the local type environment. Kind inference in ghci was interfered when renaming of type splices introduced the HsSpliced data constructor. This patch has kind inference skip over it. Test Plan: ./validate Reviewers: simonpj, rrnewton, bgamari, goldfire, austin Subscribers: thomie, mboes Differential Revision: https://phabricator.haskell.org/D2886 GHC Trac Issues: #12985 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:21:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:21:20 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.1b66463153d50d3578067546d4d0b9d8@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | ghci/scripts/GhciKinds Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/GhciKinds * status: patch => merge Comment: Thanks, Facundo! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:33:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:33:15 -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.c943f05374b0982798992612c8906b17@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I fixed that specific issue with this change {{{ diff --git a/compiler/typecheck/TcExpr.hs b/compiler/typecheck/TcExpr.hs index 39a8884..183f133 100644 --- a/compiler/typecheck/TcExpr.hs +++ b/compiler/typecheck/TcExpr.hs @@ -72,6 +72,7 @@ import FastString import Control.Monad import Class(classTyCon) import UniqFM ( nonDetEltsUFM ) +import LoadIface ( checkWiredInTyCon ) import qualified GHC.LanguageExtensions as LangExt import Data.Function @@ -441,6 +442,7 @@ tcExpr expr@(ExplicitTuple tup_args boxity) res_ty | all tupArgPresent tup_args = do { let arity = length tup_args tup_tc = tupleTyCon boxity arity + ; checkWiredInTyCon tup_tc ; res_ty <- expTypeToType res_ty ; (coi, arg_tys) <- matchExpectedTyConApp tup_tc res_ty -- Unboxed tuples have RuntimeRep vars, which we }}} but this doesn't seem like a great general approach, given that `tupleTyCon` is called from a fair number of places. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:35:28 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.b139fb1751349fe037504eda1d24110e@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:44 goldfire]: > Somehow I've not looked at this thread, finding this only by a mention of `COMPLETE` elsewhere. (This is my fault -- just explaining my silence on this topic which is in my area of interest.) > > A few nitpicks about the specification: > - The wiki page uses "total" in several places, but I think you mean "covering". I use "total" to refer to functions that are both covering and terminating. I agree with this. > - Would the following be acceptable? > > {{{ > data Void > data T = T1 Int | T2 Bool | T3 Void > {-# COMPLETE T1, T2 #-} > }}} > > It would seem so. I'm happy for this to be accepted; I'm just stress-testing the spec. Yes. > - The argument for not having the pattern-match checker look through pattern synonyms is reasonable. But is there a way to have GHC do some checking on `COMPLETE` declarations? It would be great -- especially if the `COMPLETE` pragma were in the synonyms' defining module -- to check these declarations. Of course, GHC will issue false negatives (that is, say that a set is not complete when it actually is) but some checking is better than none. There are two problems with this I think. 1. If we allow `COMPLETE` pragmas in modules other than the definition module then we would have to include the RHS of a pattern synonym in the interface file. 2. In most instances, the checker will fail and produce a warning, and then what? The warning wouldn't be actionable in some way without another syntactic clue to tell the compiler to *really* trust us. It seems like a lot of effort. > - How does this interact with GADTs? For example, load this code into your head: > > {{{ > data G a where > GInt :: G Int > GBool :: G Bool > > pattern PInt :: forall a. () => a ~ Int => G a > pattern PInt = GInt > > f1 :: G a -> () > f1 GInt = () > > f2 :: G Int -> () > f2 GInt = () > > f3 :: G Int -> () > f3 PInt = () > }}} > > By default, `f1` and `f3` will get incomplete match warnings, and `f2` does not. > > a. If I say `{-# COMPLETE GInt, GBool #-}`, does this change the default warning behavior? With my latest changes, all else being equal we choose the error from the builtin set rather than any user specified set so the warnings will remain the same. > > b. How can I have GHC notice that `f3` is a complete match? Saying `{-# COMPLETE PInt #-}` would seem disastrous. > The correct thing to specify would be `{-# COMPLETE GBool, PInt #-}` and in that case, my implementation does not warn about `f3`. > - What if multiple conflicting `COMPLETE` pragmas are in scope? For example, I have `{-# COMPLETE A, B #-}` and `{-# COMPLETE A #-}` in scope. Is a match over `A` complete? Is a warning/error issued about the pragmas? > This is a fair point. It would seem that the `A,B` pragma is redundant because `A` is a subset of `A, B` but it is possible for overlapping pragmas to make sense. For example, we could have two pattern synonyms for `Just`, `PJ1`, `PJ2` and then specify `{-# COMPLETE Nothing, PJ1 #-}` and `{-# COMPLETE Nothing, PJ2 #-}`. > - The spec says "We verify that the result types of each constructor in a complete match agrees with each other." What does this sentence mean? Consider the possibility of pattern synonyms that match against functions, polymorphic patterns, and possibly even higher-rank patterns. > It means that we look at the result type of each conlike and then verify that the type constructor for each type is the same. In the case of a set containing polymorphic patterns, at least one pattern in the set must have a definite type or you must specify a type signature to fix the type for the whole set. > I've not looked at all at the implementation, wanting to nail down the spec before considering any implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:48:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:48:51 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.a6f55e09251a767d3d9f1eb840058d46@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I feel like my suggestion, whatever it was, must have been misinterpreted... I'm concerned about situations in which there are no view patterns, at all. Take this scenario. I have a data type with a lot of `Either` fields {{{#!hs data T = T String (Either Int T) (Either Int T) (Either Int T) (Either Int T) }}} and I need to write a bunch of functions like {{{#!hs f (T s (Left _) (Left _) (Left n) (Right _)) = replicate n s f (T s (Left _) (Left n) (Right _) (Right _)) = replicate (n-1) s -- ... }}} It sure would be handy if I could define {{{#!hs pattern L <- Left _ pattern R <- Right _ }}} to condense the long left-hand sides. It just seems so obvious that I should be able to use a ''pattern synonym'' as a shorthand for a pattern, without having to go through extra contortions to appease the exhaustiveness checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:55:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:55:30 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.b91a71ec87e73b6798acc8cdfd86135d@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I was specifically referring to the second bullet point at the end of comment:31 . > GHC understands that if `p1, ..., pn` are exhaustive patterns for the result type of `f`, then `f -> p1, ..., f -> pn` are exhaustive patterns for the input type of f. This to some extent solves the problem of mixing patterns defined in different modules, as long as those patterns are defined in terms of the same "view functions". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 18:58:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 18:58:50 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.e4866d5c60b13b5554e06fed22d9ab13@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Ah okay. But that doesn't require knowing anything at all about `f`. It just requires that you used the same `f` in all the equations, and then chose a covering family `p1, ..., pn` of patterns for its output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 19:02:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 19:02:05 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.39f1f88d21d4f68c16bd9dcdb9d5b686@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): And just to say it explicitly, GHC understanding that really doesn't have anything to do with pattern synonyms at all. Even if you write a pattern match like {{{#!hs f (g -> True) = 1 f (g -> False) = 2 }}} the exhaustiveness checker thinks there are unmatched cases, but it should be able to see that there aren't. (And the desugarer already turns this into a `case` that evaluates `g` only once, so it really seems like the exhaustiveness checker ought to be able to handle this!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 19:08:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 19:08:30 -0000 Subject: [GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger In-Reply-To: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> References: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> Message-ID: <065.a9a2a9ee71e734c90a0ee06e3e0b64df@haskell.org> #13076: GHC panics can cause text-formatting changes from colorized error messages to linger -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809, #12785 | Differential Rev(s): Phab:D2932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D2932 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 19:15:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 19:15:55 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling In-Reply-To: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> References: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> Message-ID: <062.7cd83834530a24d31ae9dca83a56b3b0@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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 dobenour): * Attachment "build.2.mk" added. Another build.mk file that triggers the same panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 19:18:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 19:18:51 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling In-Reply-To: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> References: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> Message-ID: <062.560e3d3eaed586f8abf80d8f6962b109@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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): Phab:D2842 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * differential: => Phab:D2842 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 19:33:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 19:33:54 -0000 Subject: [GHC] #13048: Splitter is O(n^2) In-Reply-To: <047.258e7fedc937d14bf117b1fb536967dd@haskell.org> References: <047.258e7fedc937d14bf117b1fb536967dd@haskell.org> Message-ID: <062.90a91463cb562591d87edae690ce8796@haskell.org> #13048: Splitter is O(n^2) -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: split-objs 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 dobenour): Apparently we never hit this case, because the NCG never generates local constants anyway! This might be an NCG bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 20:03:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 20:03:17 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.91b43e997781f9914d41f73e6d6477cf@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here's another example continuing the `Either` theme. Suppose I have a synonym {{{#!hs pattern LL <- Left (Left _) }}} and a function {{{#!hs f LL = 0 f (Left (Right x)) = x f (Right y)) = -y }}} How can I get the exhaustiveness checker to accept this program with `COMPLETE`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 20:15:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 20:15:01 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.c246b7701c3be430d938330c42242027@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: 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: None/Unknown | Test Case: | perf/compiler/T13035 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): The test for this commit seems to currently be failing on all platforms https://phabricator.haskell.org/harbormaster/build/17689/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 20:23:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 20:23:38 -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.f9597f75008706d686acb2e262e646a1@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): According to ticky-ticky profiling, the big things being allocated (`alloc'd`) after the patch that caused the regression are `$j1` and `$j2` in `$s$wfoldMe`. Neither of these showed up in ticky-ticky before. I think `$j2` may be new after the patch, but `$j1` was there before; perhaps it was LNEed before and isn't now? I'll try to dig deeper on Sunday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 6 20:32:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jan 2017 20:32:03 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.09a4b53d566c6b1bc354273f68166c88@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: 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: None/Unknown | Test Case: | perf/compiler/T13035 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I believe mpickering fixed in in f3c7cf9b89cad7f326682b23d9f3908ebf0f8f9d and 54227a45352903e951b81153f798162264f02ad9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 03:14:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 03:14:56 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.5c7c8d345f1b9f64a0af4ea47a6e57d1@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.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): I have made a [https://github.com/ghc-proposals/ghc-proposals/pull/32 ghc- proposal] about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 03:23:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 03:23:51 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.db62f06e9b4b99a0fb6ff514247485ab@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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): Gosh I'm silly. The linker error is just because I have a directory named `Bug` in the same place as `Bug.hs`. I should learn to actually read error messages. I still think the program is utterly bogus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 09:42:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 09:42:02 -0000 Subject: [GHC] #13079: Fixed typo in docs Message-ID: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> #13079: Fixed typo in docs -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 09:42:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 09:42:16 -0000 Subject: [GHC] #13079: Fixed typo in docs In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.c91d7d7215a899ad1b8da8179d9588f2@haskell.org> #13079: Fixed typo in docs -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by forki): * Attachment "0001-fix-typo.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 09:43:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 09:43:54 -0000 Subject: [GHC] #13079: Fixed typo in docs In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.5d23cb8e92446c040a14c34afc103086@haskell.org> #13079: Fixed typo in docs -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by forki): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 12:36:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 12:36:52 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.f4edbf2619d27e23e37b1ed50ad49559@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 13:30:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 13:30:52 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.4d71dc541cc6cd5866d6912bbe7132c8@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): Reproduced on Linux using "+RTS -N -pa -hb -T -A6G -qg -RTS": cardano-node: internal error: Invalid object in processHeapClosureForDead(): 0 (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 13:57:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 13:57:52 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop Message-ID: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- Reporter: Feuerbach | 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 this stackoverflow post: http://stackoverflow.com/a/41521876/110081 Basically, the following program leaks memory on ghc 7.10.3 and ghc 8.0.1. {{{#!hs import Control.Monad (forever) main :: IO () main = worker {-# NOINLINE worker #-} worker :: (Monad m) => m () worker = forever $ poll () poll :: (Monad m) => () -> m a poll action = do return () poll action }}} Could ghc do better there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 14:42:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 14:42:24 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.c24a3af8834bd087950174d0ec2d762b@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- Reporter: Feuerbach | 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): Floating out `return ()` won't help much. Even if you do that, the program looks like {{{ worker = let l = poll () in forever l r = return () poll a = r >> poll a }}} so executing `l` will cause `l` to be evaluated as `r >> r >> r >> r >> ...` and we still have a live reference to `l` from within `forever`. If you instead define {{{ poll a = r >>= \_ -> poll a }}} and compile ''without optimization'' then `l` now looks like `r >>= (\_ -> ...)` and the space leak is gone. But turning on optimizations seems to cause GHC to rewrite the above to {{{ poll a = r >>= (let s = poll a in \_ -> s) }}} which now has the original problem again. (BTW I am always compiling with `-fno-state-hack`, since that just adds another layer of confusion to an already confusing situation.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 15:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 15:00:11 -0000 Subject: [GHC] #13081: Code size explosion with with inlined instances for fixed point of functor Message-ID: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> #13081: Code size explosion with with inlined instances for fixed point of functor -------------------------------------+------------------------------------- Reporter: kja | 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 | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code is not feasible to compile due to a massive explosion in "terms" generated by the simplifier as reported by `-v` flag. {{{#!hs ---[ import Data.Functor.Fixedpoint from unification-fd ]----------------- newtype Fix f = Fix { unFix :: f (Fix f) } instance (Eq (f (Fix f))) => Eq (Fix f) where x == y = unFix x == unFix y x /= y = unFix x /= unFix y -------------------------------------------------------------------------------- data Foo' a = A | B a | C a | D a a | E a a a deriving (Eq) type Foo = Fix Foo' bar :: Foo -> Foo -> m () bar t t' = if t == t' then undefined else undefined }}} Compiling with `-v` on 8.0.2 yields: {{{ [1 of 1] Compiling Lib ( src/Lib.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/Lib.o ) *** Parser [Lib]: !!! Parser [Lib]: finished in 0.90 milliseconds, allocated 0.797 megabytes *** Renamer/typechecker [Lib]: !!! Renamer/typechecker [Lib]: finished in 136.61 milliseconds, allocated 57.026 megabytes *** Desugar [Lib]: Result size of Desugar (after optimization) = {terms: 257, types: 237, coercions: 24} !!! Desugar [Lib]: finished in 2.38 milliseconds, allocated 1.264 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 297, types: 305, coercions: 18} Result size of Simplifier = {terms: 294, types: 301, coercions: 18} !!! Simplifier [Lib]: finished in 3.78 milliseconds, allocated 2.165 megabytes *** Specialise [Lib]: Result size of Specialise = {terms: 294, types: 301, coercions: 18} !!! Specialise [Lib]: finished in 0.52 milliseconds, allocated 0.382 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Lib]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 366, types: 418, coercions: 18} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Lib]: finished in 1.38 milliseconds, allocated 1.657 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 364, types: 362, coercions: 38} Result size of Simplifier iteration=2 = {terms: 311, types: 325, coercions: 38} Result size of Simplifier iteration=3 = {terms: 395, types: 417, coercions: 74} Result size of Simplifier iteration=4 = {terms: 395, types: 410, coercions: 74} Result size of Simplifier = {terms: 395, types: 410, coercions: 74} !!! Simplifier [Lib]: finished in 9.11 milliseconds, allocated 5.846 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 991, types: 1,022, coercions: 326} Result size of Simplifier iteration=2 = {terms: 991, types: 973, coercions: 326} Result size of Simplifier iteration=3 = {terms: 5,323, types: 5,433, coercions: 2,090} Result size of Simplifier iteration=4 = {terms: 5,323, types: 5,090, coercions: 2,090} Result size of Simplifier = {terms: 5,323, types: 5,090, coercions: 2,090} !!! Simplifier [Lib]: finished in 95.35 milliseconds, allocated 60.572 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 35,839, types: 36,118, coercions: 14,438} Result size of Simplifier iteration=2 = {terms: 35,839, types: 33,717, coercions: 14,438} Result size of Simplifier iteration=3 = {terms: 250,219, types: 250,145, coercions: 100,874} Result size of Simplifier iteration=4 = {terms: 250,219, types: 233,338, coercions: 100,874} Result size of Simplifier = {terms: 250,219, types: 233,338, coercions: 100,874} !!! Simplifier [Lib]: finished in 5567.46 milliseconds, allocated 2798.871 megabytes *** Float inwards [Lib]: Result size of Float inwards = {terms: 250,219, types: 233,338, coercions: 100,874} !!! Float inwards [Lib]: finished in 744.72 milliseconds, allocated 594.429 megabytes *** Called arity analysis [Lib]: Result size of Called arity analysis = {terms: 250,219, types: 233,338, coercions: 100,874} !!! Called arity analysis [Lib]: finished in 311.34 milliseconds, allocated 190.166 megabytes *** Simplifier [Lib]: }}} ... at which point it seems to "hang", though depending on hardware it might still succeed. It is clearly proportional in the number of constructors and occurrences of the type variable in those constructor. To aggravate the issue, simply add more of both. Any of ... * compiling with -O0 * adding a NOINLINE pragma to `(==)` in the instance for `Fix` * implementing a manual `Eq` instance for `Foo` and adding a NOINLINE pragma there ... solves the issue for me. Observed on both 8.0.1 (Windows and macOS) and 8.0.2 (macOS) Not present on 7.10.3 (Windows and macOS). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 15:07:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 15:07:00 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.1fb5d3f8c661d203a9c90a1a8a9300fa@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- Reporter: Feuerbach | 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 Feuerbach): I also wanted to see what difference the state hack makes, but couldn't find `-fno-stack-hack` in ghc 8 user's guide. I thought that perhaps it was replaced by a less hacky optimization in ghc 8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 15:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 15:15:18 -0000 Subject: [GHC] #13081: Code size explosion with with inlined instances for fixed point of functor In-Reply-To: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> References: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> Message-ID: <057.ac9873bbb47e1da1a2a4ea60bc8b2ff7@haskell.org> #13081: Code size explosion with with inlined instances for fixed point of functor -------------------------------------+------------------------------------- Reporter: kja | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | 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 mpickering): * status: new => closed * resolution: => duplicate Comment: It doesn't take a long time with HEAD but I'm not sure which ticket this is a duplicate of. Thanks for the nice small report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 15:19:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 15:19:50 -0000 Subject: [GHC] #13081: Code size explosion with with inlined instances for fixed point of functor In-Reply-To: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> References: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> Message-ID: <057.198b3fc538683c3b69f9ce3c3a160397@haskell.org> #13081: Code size explosion with with inlined instances for fixed point of functor -------------------------------------+------------------------------------- Reporter: kja | 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 performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: duplicate => Comment: If it's a regression from 7.10 and fixed in HEAD then it might make sense to merge the fix to 8.0.3, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 19:16:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 19:16:21 -0000 Subject: [GHC] #13081: Code size explosion with with inlined instances for fixed point of functor In-Reply-To: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> References: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> Message-ID: <057.5ad5fe8f3f83332f17e6c678c6ee8052@haskell.org> #13081: Code size explosion with with inlined instances for fixed point of functor -------------------------------------+------------------------------------- Reporter: kja | 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 performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm 90% sure it's a duplicate of #13056. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 19:18:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 19:18:42 -0000 Subject: [GHC] #13079: Fixed typo in docs In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.5e59b47846c675097cab905c143482dd@haskell.org> #13079: Fixed typo in docs -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, forki! We use Phabricator to review patches to GHC. Please refer to the instructions here on how to use it: https://ghc.haskell.org/trac/ghc/wiki/Phabricator -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 19:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 19:20:11 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.e15ff0c36f7168cdb3fc1812f8ed6251@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- Reporter: Feuerbach | 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 19:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 19:56:52 -0000 Subject: [GHC] #13081: Code size explosion with with inlined instances for fixed point of functor In-Reply-To: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> References: <042.1e1c6f32e2e3870886f9705b5244906d@haskell.org> Message-ID: <057.62e1ecc16fb41f4f74ac9a6c32c37dde@haskell.org> #13081: Code size explosion with with inlined instances for fixed point of functor -------------------------------------+------------------------------------- Reporter: kja | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | 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 RyanGlScott): * status: new => closed * resolution: => duplicate Comment: Er, #12234 rather, which has been marked as merge. I confirmed that 517d03e41b4f5c144d1ad684539340421be2be2a in particular fixed this regression. There's already been a performance test added (perf/should_compile/T12234) that's very similar in spirit to the one in this ticket, so I'll just close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 19:57:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 19:57:28 -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.7c3c1dd7839afb495de1191bd551265b@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | 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 RyanGlScott): * related: #13056 => #13056, #13081 Comment: #13081 is yet another occurrence of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 20:32:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 20:32:36 -0000 Subject: [GHC] #12498: Support unconventionally named import libraries In-Reply-To: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> References: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> Message-ID: <059.a6e0985a04515c0114f6698529331421@haskell.org> #12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 20:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 20:32:49 -0000 Subject: [GHC] #12499: Support multiple library import libs In-Reply-To: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> References: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> Message-ID: <059.8d336a1cf4f79c970b7801aa5fa20ae6@haskell.org> #12499: Support multiple library import libs -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 20:33:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 20:33:16 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.1426aa1a974146d5af4cb3403daf968e@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- 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 dfeuer): * failure: None/Unknown => Runtime performance bug * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:05:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:05:04 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.647a1f9bc369dcac81fbd965a70b2d4c@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Reid: you're probably right and the `return ()` is a red herring. I guess I still don't completely understand how this works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:29:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:29:25 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.28bfc8e834f2e676b15b5ad28c00ae36@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): The original program leaks memory even without optimization. In this case, the trouble is that {{{#!hs poll () = return () >> return () >> ... }}} `forever` always holds on to its argument, which prevents any part of `poll ()` from being collected as it's run. You can fix this (with or without optimization) by defining {{{#!hs poll _ = fix (return () >>) }}} which makes `poll ()` finite in size. While you and I both know that `forever` doesn't need to hold on to `poll ()` in this case, I don't see how GHC can be expected to see that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:36:16 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.3eecef046df540c6040f1b22f2099300@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): I missed something. It seems that `{-# NOINLINE #-}` here is effectively preventing `poll` from being specialized within its own RHS. While the constant argument ends up going away, the constant `Monad` dictionary does not. Writing {{{#!hs poll :: (Monad m) => x -> m a poll = go where go action = do return () go action }}} fixes the leak. So maybe something needs to be changed to allow internal specialization in the face of `NOINLINE`? Of course, that could have some other downside. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:39:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:39:17 -0000 Subject: [GHC] #13068: GHC should not allow modules to define instances of abstract type classes In-Reply-To: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> References: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> Message-ID: <060.0606c13394f6939751021d52c7c57c55@haskell.org> #13068: GHC should not allow modules to define instances of abstract type classes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 dfeuer): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:40:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:40:30 -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.5c9adc275f005f406336d9dc1245d696@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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:42:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:42:05 -0000 Subject: [GHC] #13073: BooleanFormula implies is wrong In-Reply-To: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> References: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> Message-ID: <060.a4e3554fe38c34986699a38f40866d3a@haskell.org> #13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.2.1 @@ -21,1 +21,2 @@ - But neither of the decomposed formulas are true. + But neither of the decomposed formulas are true, so GHC will never find a + proof. New description: The current implementation looks like this: {{{ implies :: Eq a => BooleanFormula a -> BooleanFormula a -> Bool x `implies` Var y = x `impliesAtom` y x `implies` And ys = all (implies x . unLoc) ys x `implies` Or ys = any (implies x . unLoc) ys x `implies` Parens y = x `implies` (unLoc y) }}} This cannot possibly be correct: this will decompose the formula A \/ B -> A \/ B in the following way {{{ Or [Var a, Var b] `implies` Or [Var a, Var b] Or [Var a, Var b] `implies` Var a || Or [Var a, Var b] `implies` Var b }}} But neither of the decomposed formulas are true, so GHC will never find a proof. I didn't find a case in the typechecker where this actually mattered. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:45:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:45:24 -0000 Subject: [GHC] #13080: Constant values are not floated out of the loop In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.4e708bcd07651e30eaf23d45550c928b@haskell.org> #13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by michaelt): By the way, `forever` isn't needed, you can replace it with `(\x -> x >> x)` in Feuerbach's progam. In the SO question the user noticed that the problem is solved by defining `poll a b` without explicit recursive use of `poll a b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:46:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:46:10 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.e88e36caf50110d1077df4d03703c8de@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 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 dfeuer): * status: new => closed * resolution: => invalid * milestone: => 8.0.2 Comment: There are quite a few situations in which the time can legitimately vary between evaluations. For example, {{{ > x = big_expensive_computation > f x > f x }}} If you can point out a specific example where you think the times should be similar but they are not, you can reopen this ticket with more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:50:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:50:15 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.9558b1084f78f4f3c634f8f75d042671@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: 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): * component: Compiler => Compiler (Parser) * milestone: => 8.2.1 Comment: Indeed, the program is bogus, because we have no notion of "module load time" in Haskell. It might be nice if we did, but we don't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 21:52:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 21:52:33 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal Message-ID: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this bug when I installed the `OpenAL` library from Hackage, ran it in GHCi 8.0.2, and segfaulted. Note that I've also reproduced the same error in GHC HEAD. To reproduce this bug, you'll need MSYS2. First install OpenAL: {{{ pacman -S mingw-w64-$(uname -m)-openal }}} With this Haskell file: {{{#!hs module Main (main) where import Foreign.C.Types foreign import ccall unsafe "alGetError" alGetError :: IO CInt main :: IO () main = alGetError >>= print }}} You can compile and run it without issue, using either the flag `-llibopenal` or `-lopenal` to link against OpenAL: {{{ $ ghc-8.0.2/bin/ghc -fforce-recomp -llibopenal OpenAL.hs [1 of 1] Compiling Main ( OpenAL.hs, OpenAL.o ) Linking OpenAL.exe ... $ ./OpenAL 40964 $ ghc-8.0.2/bin/ghc -fforce-recomp -lopenal OpenAL.hs $ ./OpenAL 40964 $ ghc/inplace/bin/ghc-stage2 -fforce-recomp -llibopenal OpenAL.hs [1 of 1] Compiling Main ( OpenAL.hs, OpenAL.o ) Linking OpenAL.exe ... $ ./OpenAL 40964 $ ghc/inplace/bin/ghc-stage2 -fforce-recomp -lopenal OpenAL.hs [1 of 1] Compiling Main ( OpenAL.hs, OpenAL.o ) Linking OpenAL.exe ... $ ./OpenAL 40964 }}} With GHCi, however, it gets funkier. If you pass the `-lopenal` flag, it seems to work OK: {{{ $ ghc-8.0.2/bin/runghc -lopenal OpenAL.hs 40964 $ ghc/inplace/bin/runghc -lopenal OpenAL.hs 40964 }}} But if you use the `-llibopenal` flag, it segfaults! {{{ $ runghc -llibopenal -v3 OpenAL.hs Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 8.0.1 Using binary package database: C:\Users\RyanGlScott\Software\ghc-8.0.2\lib\package.conf.d\package.cache Using binary package database: C:\Users\RyanGlScott\AppData\Roaming\ghc\x86_64-mingw32-8.0.2\package.conf.d\package.cache loading package database C:\Users\RyanGlScott\Software\ghc-8.0.2\lib\package.conf.d loading package database C:\Users\RyanGlScott\AppData\Roaming\ghc\x86_64-mingw32-8.0.2\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.212 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.133 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 2.731 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.182 megabytes *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.a" Loading package ghc-prim-0.5.0.0 ... linking ... done. Loading package integer-gmp-1.0.0.1 ... linking ... done. *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.a" Loading package base-4.9.1.0 ... linking ... done. *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "libopenal.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "libopenal.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.a" Loading object (dynamic) libopenal ... ghc.exe: addDLL: libopenal (Win32 error 126): The specified module could not be found. }}} At that point, GHC segfaults and force-quits (if you run this on PowerShell, a "ghc.exe has stopped working" message box will pop up). I don't know if #12771 is relevant. You can't test this on GHC 8.0.1 or earlier because they didn't have support for Windows import libs, which OpenAL uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 22:18:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 22:18:19 -0000 Subject: [GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger In-Reply-To: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> References: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> Message-ID: <065.76c9504920c2935c05540acbf8ae6bfd@haskell.org> #13076: GHC panics can cause text-formatting changes from colorized error messages to linger -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809, #12785 | Differential Rev(s): Phab:D2932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => high * status: new => patch * milestone: => 8.2.1 Comment: I'm bumping the priority on this because it really messes with users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 22:46:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 22:46:57 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal In-Reply-To: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> References: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> Message-ID: <065.51a1a3a1a4276b7b3614c8d74412a626@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 22:56:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 22:56:58 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.5e6d966fd8a620cac5c8aa8f9f2f120a@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => low * milestone: => 8.2.1 Comment: I'm setting a low priority for this, even though it's a regression. As Reid indicates, it doesn't affect whether there's a redundant import warning, or whether the warning is correct, but only precisely which import is reported as redundant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 23:06:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 23:06:37 -0000 Subject: [GHC] #13079: Fix typo in comment (was: Fixed typo in docs) In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.4a4de10576bfb8b5abf8244370474ecf@haskell.org> #13079: Fix typo in comment -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.2.1 * differential: => Phab:D2939 @@ -1,1 +1,1 @@ - + "threshold" is misspelled "threshhold" in `compiler/utils/Util.hs`. New description: "threshold" is misspelled "threshhold" in `compiler/utils/Util.hs`. -- Comment: Differential submitted to Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 7 23:18:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jan 2017 23:18:25 -0000 Subject: [GHC] #13063: Program uses 8GB of memory In-Reply-To: <047.30ffe259e5b1cc90f33cfba9e08ebbbc@haskell.org> References: <047.30ffe259e5b1cc90f33cfba9e08ebbbc@haskell.org> Message-ID: <062.cf272ec74daad14560591f15a7a605fa@haskell.org> #13063: Program uses 8GB of memory -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Can you explain how to reproduce this using GHC HEAD? Can you reduce it to a smaller example? Do you see a similar problem with 7.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 00:06:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 00:06:02 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.a3caf7fe0005b4d0df4a8eb36a792427@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): One place I think we still can't derive (seemingly reasonable) `Generic` instances is with GADTs. For example, today I can write {{{#!hs {-# LANGUAGE DeriveGeneric, StandaloneDeriving, GADTs, DataKinds, KindSignatures, FlexibleInstances, TypeFamilies #-} module GenGADT where import GHC.Generics data Foo :: Bool -> * -> * where X :: a -> Foo 'False a Y :: a -> Foo 'True a instance Generic (Foo 'False a) where type Rep (Foo 'False a) = D1 ('MetaData "Foo 'False" "GenGADT" "" 'False) (C1 ('MetaCons "X" 'PrefixI 'False) (Rec0 a)) to (M1 (M1 (K1 a))) = X a from (X a) = M1 (M1 (K1 a)) instance Generic (Foo 'True a) where type Rep (Foo 'True a) = D1 ('MetaData "Foo 'True" "GenGADT" "" 'False) (C1 ('MetaCons "Y" 'PrefixI 'False) (Rec0 a)) to (M1 (M1 (K1 a))) = Y a from (Y a) = M1 (M1 (K1 a)) }}} but I don't think GHC is able to derive such instances. I'm more concerned about backwards compatibility issues, though. As soon as a library chooses to derive a `Generic` instance for a type, that instance becomes part of the library API. Users may well come to rely on the existence of that instance, and also some of its details. If we prohibit custom instances, won't that strongly discourage libraries from deriving `Generic` for any but the most trivial exposed types? Let me get back to pattern synonyms. Suppose we have {{{#!hs data Tree a = Tree a [Tree a] deriving Generic }}} and we decide we want to play around with bifunctors, so we redefine this as {{{#!hs --newtype Fix p a = In {out :: p (Fix p a) a} --instance Bifunctor p => Functor (Fix p) where ... data TreeF t a = TreeF a [t] instance Bifunctor TreeF where ... newtype Tree a = Tree (Fix Tree) deriving Functor -- et cetera }}} We can recover most of the original interface using bidirectional pattern synonyms to work around the newtypes. But if we can't write our own `Generic` instance, we'll break everything. Existing library users won't define instances for `TreeF`, so their `Generic`-derived instances for `Tree` will no longer pass the type checker. Ouch. A recent `containers` version added `Generic` and `Generic1` for `Data.Tree`; had the prohibition been under discussion at the time, I'd have thought twice and thrice about whether that was wise. I don't think this issue was quite as significant before the rise of pattern synonyms; in that era, any structural change to an exported transparent datatype was necessarily a breaking one. With pattern synonyms, there are more places we ''can'' change representations, and therefore more reasons to avoid preventing such changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 00:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 00:17:19 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy In-Reply-To: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> References: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> Message-ID: <059.5ee2b631e5a61c47dfba55dcfe66c1c4@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: SafeHaskell, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2546 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"7b317effd59f56bc8450ea8efbb1ef5954f09e5d/ghc" 7b317ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b317effd59f56bc8450ea8efbb1ef5954f09e5d" TH: Add Trustworthy language pragma Test Plan: validate Reviewers: goldfire, bgamari, austin, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, simonpj, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D2546 GHC Trac Issues: #12511 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 00:23:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 00:23:46 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.ffd99d2861a138ad461495e1b6a9b31a@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): GHC isn't able to derive `Generic` instances for GADTs since as it stands today, there's no sensible way to do it. The ones you hand-defined are bogus, since they would have you believe that there's //two// separate datatypes named `Foo`, each with different constructors. And then there's the separate issue that they don't capture the `'True` and `'False` existential equality information. I don't see what pattern synonyms change here. The issue is fundamentally about what promises `Generic` instances make, and if we want them to be honest, then we cannot allow hand-defined `Generic` instances at all, even if they might be temptingly convenient. `GHC.Generics` is a feature which necessarily mirrors the definition of datatype, so if a datatype's internal structure changes, then its `Generic` instance must change too. Full stop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 00:36:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 00:36:25 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.770e8f0f68bb3e7fb32347bb58f9a449@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): In my patch I do see `dyn_hi` being generated. So that should be fine now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 00:36:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 00:36:46 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.ed4448d5a3cad9e572059343182d6aa5@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 01:28:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 01:28:35 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype Message-ID: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: Coercible | 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: -------------------------------------+------------------------------------- I'm getting a type error using `coerce` to remove the wrapper of a `newtype` specialization involving a the following. See below for the smallest example I was able to construct. {{{#!hs {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wall #-} -- | Bug(?) in Coercible constraint solving -- module B2 where import GHC.Generics (Par1(..),(:*:)(..)) import GHC.Exts (coerce) -- Representation as free vector space type family V (a :: *) :: * -> * type instance V Float = Par1 type instance V (a,b) = V a :*: V b type instance V (Par1 a) = V a type instance V ((f :*: g) a) = V (f a, g a) -- • Variable ‘a’ occurs more often -- in the type family application ‘V (f a, g a)’ -- than in the instance head -- (Use UndecidableInstances to permit this) type R = Float -- Linear map in row-major order newtype L a b = L (V b (V a R)) -- Use coerce to drop newtype wrapper bar :: L a b -> V b (V a R) bar = coerce {-------------------------------------------------------------------- Bug demo --------------------------------------------------------------------} -- A rejected type specialization of bar with a ~ (R,R), b ~ (Par1 R,R) foo :: L (R,R) (Par1 R,R) -> V (Par1 R,R) (V (R,R) R) foo = coerce -- • Couldn't match representation of type ‘V Par1’ -- with that of ‘Par1’ -- arising from a use of ‘coerce’ -- Note that Par1 has the wrong kind (* -> *) for V Par1 -- Same error: -- -- foo :: (a ~ (R,R), b ~ (Par1 R,R)) => L a b -> V b (V a R) -- The following similar signatures work: -- foo :: L (R,R) (R,Par1 R) -> V (R,Par1 R) (V (R,R) R) -- foo :: L (Par1 R,R) (R,R) -> V (R,R) (V (Par1 R,R) R) -- Same error: -- -- Linear map in column-major order -- newtype L a b = L (V a (V b s)) -- foo :: L (R,R) (Par1 R,R) -> V (R,R) (V (Par1 R,R) R) -- foo = coerce }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 02:11:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 02:11:35 -0000 Subject: [GHC] #13084: 'foreign import prim' are marked PlaySafe by the parser Message-ID: <048.4b89f1d732f141f887872f7aef28e459@haskell.org> #13084: 'foreign import prim' are marked PlaySafe by the parser -------------------------------------+------------------------------------- Reporter: jberryman | 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: -------------------------------------+------------------------------------- Experimenting with a {{{foreign import prim}}} in my code I noticed the generated core produces {{{__pkg_ccall_GC}}} which concerned me since I thought perhaps we were experiencing the overhead of a "safe" ccall. Reid Barton reccommended filing a report, commenting: it looks like prim imports are marked PlaySafe by the parser, which is presumably mostly ignored, and definitely ignored during code generation. But wherever it's not ignored there could be a bug see: http://stackoverflow.com/questions/41528208/why-is-there-no-foreign- import-prim-unsafe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 03:50:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 03:50:56 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy In-Reply-To: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> References: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> Message-ID: <059.8b75b9aff5c66148f6f12b435589e8c5@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: SafeHaskell, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2546 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 03:51:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 03:51:20 -0000 Subject: [GHC] #13085: -fregs-graph is ignored but this is undocumented Message-ID: <048.179c57af2638d63782eeaa4e29c25b37@haskell.org> #13085: -fregs-graph is ignored but this is undocumented -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- This is bad since it can be a time sink experimenting with knobs, especially if you're staring at assembly, etc. so this is a documentation bug. I'm confused about what happened with this flag. It was ignored at some point, recently restored but then that was reverted without fixing the docs I guess: https://phabricator.haskell.org/rGHC6a5d13c4ade5bbb84873970065a1acd1546f6c31 https://phabricator.haskell.org/rGHC55dfd21e1969b4b8e40196ecf29e4c9c73273966 https://ghc.haskell.org/trac/ghc/ticket/13033 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 04:03:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 04:03:42 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.36822f7e745e2cdbaef92787b40b47af@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible 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 RyanGlScott): * cc: goldfire (added) Comment: I believe this is expected behavior. You can only coerce from `V Par1` to `Par` if the [https://ghc.haskell.org/trac/ghc/wiki/Roles role] of `V1`'s argument is permissive enough (that is, it must have a representational or phantom role, not a nominal role). But currently, all arguments to a type family (such as `V`) are always assigned nominal roles. This solves problems like the [https://ghc.haskell.org/trac/ghc/wiki/Roles#Theproblemwewishtosolve original motivation for roles], but it does rule out scenarios like yours. FWIW, I've been advocating for role inference/the ability to give type families role annotations in #8177. I think a type family like: {{{#!hs type family Id a where Id a = a }}} should definitely be able to have a representational role for its argument. Not sure about `V`, though. I'll cc goldfire for his thoughts as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 04:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 04:07:05 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.bc921a2ca5b5713aaaded3bfb90ac9ed@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2940 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harendra): * differential: => D2940 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 04:53:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 04:53:35 -0000 Subject: [GHC] #13050: Holes don't work infix In-Reply-To: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> References: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> Message-ID: <066.78aa5d6e6736b4bc4141c7e8bf3c211b@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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:D2910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"6c869f906b879bc746ea1aa3e79e02f146d85093/ghc" 6c869f90/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c869f906b879bc746ea1aa3e79e02f146d85093" Parse holes as infix operators Reported as #13050. Since holes are expressions but not identifiers, holes were not allowed in infix operator position. This patch introduces a new production in infix operator parser to allow this. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: simonpj, RyanGlScott, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2910 GHC Trac Issues: #13050 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 04:57:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 04:57:25 -0000 Subject: [GHC] #13050: Holes don't work infix In-Reply-To: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> References: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> Message-ID: <066.af650dfe93c2ea2f18ce8fbf6330cd9e@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: merge 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:D2910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 05:09:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 05:09:56 -0000 Subject: [GHC] #13086: (\\) in Data.List uses foldl instead of foldl' Message-ID: <051.56cb8d8a52c90e7b74e3b3342d64759a@haskell.org> #13086: (\\) in Data.List uses foldl instead of foldl' -------------------------------------+------------------------------------- Reporter: vaibhavsagar | 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: -------------------------------------+------------------------------------- The list difference operator `(\\)` is currently defined in terms of `foldl`: https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Data.OldList.html#%5C%5C. Should it be using `foldl'` instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 06:12:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 06:12:35 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal In-Reply-To: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> References: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> Message-ID: <065.74b9208de81f3242881b62d2942f011a@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Thanks for the report @RyanGIScott -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 06:13:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 06:13:20 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal In-Reply-To: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> References: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> Message-ID: <065.55a7d215ca73f6aa8d7419499d61089a@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: T13082_good, | T13082_fail Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2941 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * testcase: => T13082_good, T13082_fail * status: new => patch * differential: => Phab:D2941 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 08:23:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 08:23:45 -0000 Subject: [GHC] #13079: Fix typo in comment In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.0b975d82eb1977b6784c5db02fa319b0@haskell.org> #13079: Fix typo in comment -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by forki): @RyanGlScott I did what HACKING.m/"Contributing patches to GHC in a hurry" said. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 09:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 09:06:11 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase Message-ID: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE AlternativeLayoutRule #-} {-# LANGUAGE LambdaCase #-} isOne :: Int -> Bool isOne = \case 1 -> True _ -> False main = return () }}} {{{ $ ghc test-case [1 of 1] Compiling Main ( test-case.hs, test-case.o ) test-case.hs:5:15: error: parse error on input ‘1’ }}} It compiles fine without the AlternativeLayoutRule extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 10:41:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 10:41:20 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.9baf46d044276c1d36315298c640160a@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm wondering how you found that flag. I did some digging, it seems like that feature was added with https://github.com/ghc/ghc/commit/16c7844d and later used in https://github.com/ghc/ghc/commit/4edbeb14e to as a part of GHCi's `:m` (which is probably the same thing with `:set +m`). It was never documented, and currently it's not even listed in GHC's man page or user manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 11:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 11:07:01 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.80c3a356ce864c4f87c2c7191986eaea@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest 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 phadej): With https://gist.github.com/phadej/fdd74f4b4b40dc0a758ca6192cd66e83 I can successfully run the doctests in `base`. There's a hack, it picks files based on whether there is `$setup`, which IMHO is not so bad assumption. If someone could give a pointer how to integrate it with `validate`, I probably can do it. Yet, i'd like to have ability to run the doctests in standalone way, as editing docs / doctests shouldn't require rebuilds of the `base` etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 14:14:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 14:14:07 -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.e100069d31ecf6ebb8710b4f964fb0ca@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 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-): * differential: Phab:D2917 => Phab:D2917 Phab:/D2942 Comment: Added another possible fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 14:41:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 14:41:03 -0000 Subject: [GHC] #13086: (\\) in Data.List uses foldl instead of foldl' In-Reply-To: <051.56cb8d8a52c90e7b74e3b3342d64759a@haskell.org> References: <051.56cb8d8a52c90e7b74e3b3342d64759a@haskell.org> Message-ID: <066.f9aa182472155d19d8e2c5ea7755ddcd@haskell.org> #13086: (\\) in Data.List uses foldl instead of foldl' -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It probably doesn’t make a difference. The accumulator here is of type `[a]` and the function passed to `foldl` is `delete`, which is lazy. So forcing the first element of the list will make `delete` only progress until the next retained element of the list, but the rest will still be a thunk. If you show some benchmarks indicating genuine improvement, we can certainly change this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 15:06:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 15:06:39 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.364135aa03fe61c6caf6244324ea8ad7@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible 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 goldfire): I'm afraid I don't see how comment:1 applies. The type of `foo` seems to be a straightforward specialization of the type of `bar`. So it seems this should work. Confirmed reproducible in a fairly recent HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 15:09:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 15:09:02 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.10207c75eb8a7a64590d297eccef8a53@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible 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 RyanGlScott): Derp, I didn't read the source closely enough. In particular, I missed this more glaring issue: {{{#!hs -- Note that Par1 has the wrong kind (* -> *) for V Par1 }}} So please ignore everything I said in comment:1 :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 17:51:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 17:51:46 -0000 Subject: [GHC] #13088: Type operator holes don't work infix Message-ID: <050.1af5ba8b7425e07e484652f2ce9c33ca@haskell.org> #13088: Type operator holes don't work infix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #13050 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally noted in https://phabricator.haskell.org/D2910 (which fixed #13050). Currently, you can do this: Does this also work with TypeOperators? That is, you can do this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_over` b -> _over a b foo = id }}} But not this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_` b -> over a b foo = id }}} osa1 made an attempt at fixing this, and recorded his progress [https://phabricator.haskell.org/D2910#85423 here]: > I played with alternative implementations and attempted at implementing type-level version of this patch as suggested by @RyanGlScott. > > Since `_` needs special treatment by the renamer I think we have to have some kind of special treatment for `_` in the parser too, so this implementation may not be too bad. > > (alternatively I guess we could remove special treatment for `_` in the parser but that'd just move special cases to the renamer, so I'm not sure that's any better than the current approach) > > About the type-level named infix holes: Type renamer is quite different than term renamer (`RnTypes.hs`) and I don't understand type-checker parts of the compiler -- but I was able to made an attempt at implementing this > > {{{#!diff > diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs > index 53f200f..877c243 100644 > --- a/compiler/hsSyn/HsTypes.hs > +++ b/compiler/hsSyn/HsTypes.hs > @@ -608,6 +608,7 @@ type LHsAppType name = Located (HsAppType name) > data HsAppType name > = HsAppInfix (Located name) -- either a symbol or an id in backticks > | HsAppPrefix (LHsType name) -- anything else, including things like (+) > + | HsAppWild (Located (HsWildCardInfo name)) > deriving instance (DataId name) => Data (HsAppType name) > > instance (OutputableBndrId name) => Outputable (HsAppType name) where > @@ -987,11 +988,18 @@ getAppsTyHead_maybe tys = case splitHsAppsTy tys of > splitHsAppsTy :: [LHsAppType name] -> ([[LHsType name]], [Located name]) > splitHsAppsTy = go [] [] [] > where > + go :: [LHsType name] > + -> [[LHsType name]] > + -> [Located name] > + -> [LHsAppType name] > + -> ([[LHsType name]], [Located name]) > go acc acc_non acc_sym [] = (reverse (reverse acc : acc_non), reverse acc_sym) > go acc acc_non acc_sym (L _ (HsAppPrefix ty) : rest) > = go (ty : acc) acc_non acc_sym rest > go acc acc_non acc_sym (L _ (HsAppInfix op) : rest) > = go [] (reverse acc : acc_non) (op : acc_sym) rest > + go acc acc_non acc_sym (L l (HsAppWild (L _ wc)) : rest) > + = go (L l (HsWildCardTy wc) : acc) acc_non acc_sym rest > > -- Retrieve the name of the "head" of a nested type application > -- somewhat like splitHsAppTys, but a little more thorough > @@ -1334,14 +1342,18 @@ ppr_fun_ty ctxt_prec ty1 ty2 > > -------------------------- > ppr_app_ty :: (OutputableBndrId name) => TyPrec -> HsAppType name -> SDoc > -ppr_app_ty _ (HsAppInfix (L _ n)) = pprInfixOcc n > +ppr_app_ty _ (HsAppInfix (L _ n)) > + = pprInfixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar NotPromoted (L _ n)))) > = pprPrefixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar Promoted (L _ n)))) > = space <> quote (pprPrefixOcc n) -- We need a space before the ' above, so > -- the parser does not attach it to the > -- previous symbol > -ppr_app_ty ctxt (HsAppPrefix ty) = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppPrefix ty) > + = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppWild (L _ (AnonWildCard _))) > + = empty -- FIXME > > -------------------------- > ppr_tylit :: HsTyLit -> SDoc > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > index dfb6755..da4696a 100644 > --- a/compiler/parser/Parser.y > +++ b/compiler/parser/Parser.y > @@ -1833,6 +1833,7 @@ tyapp :: { LHsAppType RdrName } > [mj AnnSimpleQuote $1] } > | SIMPLEQUOTE varop {% ams (sLL $1 $> $ HsAppInfix $2) > [mj AnnSimpleQuote $1] } > + | '`' '_' '`' { sL1 $1 (HsAppWild (sL1 $1 (AnonWildCard PlaceHolder))) } > > atype :: { LHsType RdrName } > : ntgtycon { sL1 $1 (HsTyVar NotPromoted $1) } -- Not including unit tuples > diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs > index f3fcf88..9298020 100644 > --- a/compiler/rename/RnTypes.hs > +++ b/compiler/rename/RnTypes.hs > @@ -1050,8 +1050,11 @@ collectAnonWildCards lty = go lty > > gos = mconcat . map go > > + prefix_types_only :: HsAppType Name -> Maybe (LHsType Name) > prefix_types_only (HsAppPrefix ty) = Just ty > prefix_types_only (HsAppInfix _) = Nothing > + prefix_types_only (HsAppWild (L l (AnonWildCard wc_name))) = > + Just (L l (HsWildCardTy (AnonWildCard wc_name))) > > collectAnonWildCardsBndrs :: [LHsTyVarBndr Name] -> [Name] > collectAnonWildCardsBndrs ltvs = concatMap (go . unLoc) ltvs > @@ -1646,8 +1649,9 @@ extract_apps t_or_k tys acc = foldrM (extract_app t_or_k) acc tys > > extract_app :: TypeOrKind -> LHsAppType RdrName -> FreeKiTyVars > -> RnM FreeKiTyVars > -extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > -extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > +extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppWild (L l wc))) acc = extract_lty t_or_k (L l (HsWildCardTy wc)) acc > > extract_hs_tv_bndrs :: [LHsTyVarBndr RdrName] -> FreeKiTyVars > -> FreeKiTyVars -> RnM FreeKiTyVars > }}} > > Once I figure out how to do the `FIXME` part this patch may just work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 17:52:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 17:52:42 -0000 Subject: [GHC] #13050: Holes don't work infix In-Reply-To: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> References: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> Message-ID: <066.8876e6f161fedb01747eb311fca6b8e6@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: None/Unknown | Test Case: | typecheck/should_compile/T13050 Blocked By: | Blocking: Related Tickets: #13088 | Differential Rev(s): Phab:D2910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T13050 * related: => #13088 * milestone: => 8.0.3 Comment: I've opened #13088 to track the remaining issue (type operator holes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 17:53:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 17:53:12 -0000 Subject: [GHC] #13088: Type operator holes don't work infix In-Reply-To: <050.1af5ba8b7425e07e484652f2ce9c33ca@haskell.org> References: <050.1af5ba8b7425e07e484652f2ce9c33ca@haskell.org> Message-ID: <065.760e9ad819260d0e874a5a3a864f3a8a@haskell.org> #13088: Type operator holes don't work infix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13050 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -3,2 +3,0 @@ - - Does this also work with TypeOperators? That is, you can do this: New description: Originally noted in https://phabricator.haskell.org/D2910 (which fixed #13050). Currently, you can do this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_over` b -> _over a b foo = id }}} But not this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_` b -> over a b foo = id }}} osa1 made an attempt at fixing this, and recorded his progress [https://phabricator.haskell.org/D2910#85423 here]: > I played with alternative implementations and attempted at implementing type-level version of this patch as suggested by @RyanGlScott. > > Since `_` needs special treatment by the renamer I think we have to have some kind of special treatment for `_` in the parser too, so this implementation may not be too bad. > > (alternatively I guess we could remove special treatment for `_` in the parser but that'd just move special cases to the renamer, so I'm not sure that's any better than the current approach) > > About the type-level named infix holes: Type renamer is quite different than term renamer (`RnTypes.hs`) and I don't understand type-checker parts of the compiler -- but I was able to made an attempt at implementing this > > {{{#!diff > diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs > index 53f200f..877c243 100644 > --- a/compiler/hsSyn/HsTypes.hs > +++ b/compiler/hsSyn/HsTypes.hs > @@ -608,6 +608,7 @@ type LHsAppType name = Located (HsAppType name) > data HsAppType name > = HsAppInfix (Located name) -- either a symbol or an id in backticks > | HsAppPrefix (LHsType name) -- anything else, including things like (+) > + | HsAppWild (Located (HsWildCardInfo name)) > deriving instance (DataId name) => Data (HsAppType name) > > instance (OutputableBndrId name) => Outputable (HsAppType name) where > @@ -987,11 +988,18 @@ getAppsTyHead_maybe tys = case splitHsAppsTy tys of > splitHsAppsTy :: [LHsAppType name] -> ([[LHsType name]], [Located name]) > splitHsAppsTy = go [] [] [] > where > + go :: [LHsType name] > + -> [[LHsType name]] > + -> [Located name] > + -> [LHsAppType name] > + -> ([[LHsType name]], [Located name]) > go acc acc_non acc_sym [] = (reverse (reverse acc : acc_non), reverse acc_sym) > go acc acc_non acc_sym (L _ (HsAppPrefix ty) : rest) > = go (ty : acc) acc_non acc_sym rest > go acc acc_non acc_sym (L _ (HsAppInfix op) : rest) > = go [] (reverse acc : acc_non) (op : acc_sym) rest > + go acc acc_non acc_sym (L l (HsAppWild (L _ wc)) : rest) > + = go (L l (HsWildCardTy wc) : acc) acc_non acc_sym rest > > -- Retrieve the name of the "head" of a nested type application > -- somewhat like splitHsAppTys, but a little more thorough > @@ -1334,14 +1342,18 @@ ppr_fun_ty ctxt_prec ty1 ty2 > > -------------------------- > ppr_app_ty :: (OutputableBndrId name) => TyPrec -> HsAppType name -> SDoc > -ppr_app_ty _ (HsAppInfix (L _ n)) = pprInfixOcc n > +ppr_app_ty _ (HsAppInfix (L _ n)) > + = pprInfixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar NotPromoted (L _ n)))) > = pprPrefixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar Promoted (L _ n)))) > = space <> quote (pprPrefixOcc n) -- We need a space before the ' above, so > -- the parser does not attach it to the > -- previous symbol > -ppr_app_ty ctxt (HsAppPrefix ty) = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppPrefix ty) > + = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppWild (L _ (AnonWildCard _))) > + = empty -- FIXME > > -------------------------- > ppr_tylit :: HsTyLit -> SDoc > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > index dfb6755..da4696a 100644 > --- a/compiler/parser/Parser.y > +++ b/compiler/parser/Parser.y > @@ -1833,6 +1833,7 @@ tyapp :: { LHsAppType RdrName } > [mj AnnSimpleQuote $1] } > | SIMPLEQUOTE varop {% ams (sLL $1 $> $ HsAppInfix $2) > [mj AnnSimpleQuote $1] } > + | '`' '_' '`' { sL1 $1 (HsAppWild (sL1 $1 (AnonWildCard PlaceHolder))) } > > atype :: { LHsType RdrName } > : ntgtycon { sL1 $1 (HsTyVar NotPromoted $1) } -- Not including unit tuples > diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs > index f3fcf88..9298020 100644 > --- a/compiler/rename/RnTypes.hs > +++ b/compiler/rename/RnTypes.hs > @@ -1050,8 +1050,11 @@ collectAnonWildCards lty = go lty > > gos = mconcat . map go > > + prefix_types_only :: HsAppType Name -> Maybe (LHsType Name) > prefix_types_only (HsAppPrefix ty) = Just ty > prefix_types_only (HsAppInfix _) = Nothing > + prefix_types_only (HsAppWild (L l (AnonWildCard wc_name))) = > + Just (L l (HsWildCardTy (AnonWildCard wc_name))) > > collectAnonWildCardsBndrs :: [LHsTyVarBndr Name] -> [Name] > collectAnonWildCardsBndrs ltvs = concatMap (go . unLoc) ltvs > @@ -1646,8 +1649,9 @@ extract_apps t_or_k tys acc = foldrM (extract_app t_or_k) acc tys > > extract_app :: TypeOrKind -> LHsAppType RdrName -> FreeKiTyVars > -> RnM FreeKiTyVars > -extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > -extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > +extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppWild (L l wc))) acc = extract_lty t_or_k (L l (HsWildCardTy wc)) acc > > extract_hs_tv_bndrs :: [LHsTyVarBndr RdrName] -> FreeKiTyVars > -> FreeKiTyVars -> RnM FreeKiTyVars > }}} > > Once I figure out how to do the `FIXME` part this patch may just work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 20:42:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 20:42:43 -0000 Subject: [GHC] #13089: GHC panic Message-ID: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> #13089: GHC panic -------------------------------------+------------------------------------- Reporter: cbaatz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I stumbled upon a GHC panic for some reason. Not sure how to debug this/get more details on it so attaching the error message: ``` ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 21:06:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 21:06:38 -0000 Subject: [GHC] #13089: GHC panics on some imports from the Repa package (was: GHC panic) In-Reply-To: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> References: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> Message-ID: <060.5559c3c5174217a53123a32c96fd6741@haskell.org> #13089: GHC panics on some imports from the Repa package -------------------------------------+------------------------------------- Reporter: cbaatz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by cbaatz: @@ -1,2 +1,9 @@ - I stumbled upon a GHC panic for some reason. Not sure how to debug - this/get more details on it so attaching the error message: + I stumbled upon a GHC panic for some reason. The error message is below. + The error disappears when I replace: + + import Data.Array.Repa ((:.) (..), Array, DIM1, DIM2, U, Z + (..)) + + with + + import Data.Array.Repa hiding ((++)) New description: I stumbled upon a GHC panic for some reason. The error message is below. The error disappears when I replace: import Data.Array.Repa ((:.) (..), Array, DIM1, DIM2, U, Z (..)) with import Data.Array.Repa hiding ((++)) ``` ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) ``` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 21:12:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 21:12:40 -0000 Subject: [GHC] #13089: GHC panics when importing Array from Data.Array.Repa (was: GHC panics on some imports from the Repa package) In-Reply-To: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> References: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> Message-ID: <060.fcf9bb4bd4c0483f0a35ac3c32918ab3@haskell.org> #13089: GHC panics when importing Array from Data.Array.Repa -------------------------------------+------------------------------------- Reporter: cbaatz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by cbaatz: @@ -9,1 +9,5 @@ - import Data.Array.Repa hiding ((++)) + import Data.Array.Repa ((:.) (..), DIM1, DIM2, U, Z (..)) + + and I've confirmed that it panics with: + + import Data.Array.Repa (Array) New description: I stumbled upon a GHC panic for some reason. The error message is below. The error disappears when I replace: import Data.Array.Repa ((:.) (..), Array, DIM1, DIM2, U, Z (..)) with import Data.Array.Repa ((:.) (..), DIM1, DIM2, U, Z (..)) and I've confirmed that it panics with: import Data.Array.Repa (Array) ``` ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) ``` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 21:30:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 21:30:33 -0000 Subject: [GHC] #13089: GHC panics when importing Array from Data.Array.Repa In-Reply-To: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> References: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> Message-ID: <060.cdd215a12440491d40fa3888ae54d85e@haskell.org> #13089: GHC panics when importing Array from Data.Array.Repa -------------------------------------+------------------------------------- Reporter: cbaatz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -4,0 +4,1 @@ + {{{#!hs @@ -6,0 +7,1 @@ + }}} @@ -9,0 +11,1 @@ + {{{#!hs @@ -10,0 +13,1 @@ + }}} @@ -15,1 +19,1 @@ - ``` + {{{ @@ -28,1 +32,1 @@ - ``` + }}} New description: I stumbled upon a GHC panic for some reason. The error message is below. The error disappears when I replace: {{{#!hs import Data.Array.Repa ((:.) (..), Array, DIM1, DIM2, U, Z (..)) }}} with {{{#!hs import Data.Array.Repa ((:.) (..), DIM1, DIM2, U, Z (..)) }}} and I've confirmed that it panics with: import Data.Array.Repa (Array) {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 8 22:03:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jan 2017 22:03:57 -0000 Subject: [GHC] #13089: GHC panics when importing Array from Data.Array.Repa In-Reply-To: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> References: <045.76a4bc2eea41e056c7e61b9affd30cb8@haskell.org> Message-ID: <060.d2843d6b52ad599d6ab1c31c27772a03@haskell.org> #13089: GHC panics when importing Array from Data.Array.Repa -------------------------------------+------------------------------------- Reporter: cbaatz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12127 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12127 Comment: Thanks for the report. This turns out to be a duplicate of #12127, which was fixed in the 8.0.2 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 04:37:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 04:37:09 -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.17e8df31b79bd616ab02bdafd311d4f4@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "Main.dump-stg.gz" added. STG dump for HEAD c. Jan 8 2017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 04:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 04:37:47 -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.33a234b9cbf9723e91662c26aa65b1e8@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "headallocd.ticky" added. ticky-ticky profile for HEAD c. Jan 8, 2017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 04:42:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 04:42:43 -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.82bdf05fffea7b92158e6f4f4a03cf15@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm seeing a lot of allocation of `j2_sbYy`. It seems this is not let-no- escape because it's used in non-tail position. But every use site looks identical (modulo distinctions that at least ''shouldn't'' matter). Specifically, an application of `j2_sbYy` is case-matched, and the non-`void#` portion of the result is passed to `$j3_sbZZ`. Something must be preventing GHC from seeing that `j2_sbYy` should itself call `$j3_sbZZ`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 08:59:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 08:59:06 -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.e5986fb1a6df138ff07a86fabe8899d0@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Well that is indeed odd. I'd expect to see a `checkWiredInTyCon` in all the places in the typechecker where an explicit tuple occurs, namely * In the `ExplicitTuple` case of `TcExpr`. (Don't forget the not tup-args- all-present case.) * In the `HsTypleTy` case of `TcHsType.tc_hs_type`. (I think the best place would be in `finish_tuple`.) How does it work at the moment? It looks as if the instances for tuples are defined with the relevant ''classes'' (e.g `Eq` in `GHC.Classes`). And that is loaded whenever the class is loaded, so we won't see any missing instances for tuples. That looks like a fluke to me. Incidentally, you might want to do the same big-tuple thing for the constraint tuples in `GHC.Classes`, which is almost invariably loaded. (Use `-ddump-if-trace` to see.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:19:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:19:07 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.fc5addac502061bd5dafd345917dc19e@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Reid wants the pattern-match completeness check to be able to "see through" the definition of a pattern synonym. That is, he wants the client of `LL` in comment:51 to be able to see that `LL` is no more than `(Left (Left _))`. But currently pattern synonyms are set up to exploit ''abstraction''. All the client knows is the type of `LL`; and the names and types of a matching and building function for it. We have no mechanism at all for exposing `LL`'s implementation in an interface file, to client modules. That's not quite true: we have the unfolding for `LL`'s matching function. So in certain cases, where `LL` is simple, the unfolding tells you all about it. But that's pretty fragile (it might change if `LL` got a bit bigger) and it's not information that is easy for the pattern-match overlap checker to exploit --- for example the unfolding of the matcher might be cluttered with stuff to do with re-boxing arguments that had been UNPACKed. I'm not arguing for a particular way forward here; just trying to explain why the context makes it hard to do what Reid wants. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:21:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:21:39 -0000 Subject: [GHC] #13078: Panic from ghc-stage1 when building HEAD with profiling In-Reply-To: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> References: <047.2b88eb971421578e93c3075fb243e0bc@haskell.org> Message-ID: <062.08ed3d147f7f1028af659176a9ec7826@haskell.org> #13078: Panic from ghc-stage1 when building HEAD with profiling -------------------------------------+------------------------------------- Reporter: dobenour | 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): Phab:D2842 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): By adding Phab:D2842, do you mean that you've checked that Richard's patch cures the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:22:50 -0000 Subject: [GHC] #13090: Expose all unfoldings of overloaded functions by default Message-ID: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> #13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2929 | Wiki Page: -------------------------------------+------------------------------------- Users expect their overloaded functions to be specialised at call sites, however, this is only the case if they are either lucky and GHC chooses to include the unfolding or they mark their definition with an INLINABLE pragma. This leads to library authors marking all their functions with INLINABLE (or more accurately INLINE) so they ensure that downstream consumers pay no cost for their abstraction. A more sensible default is to do this job for the library author and give more predictable guarantees about specialisation. Empirically, I compiled a selection of 1150 packages with (a similar) patch applied. The total size of the interface files before the patch was 519mb and after 634mb. On modern machines, I think this increase is justified for the result. This is a ticket to track the progress of D2929. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:23:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:23:22 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.6c3dedd458b721b872e5edffb15fd3a5@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: 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: None/Unknown | Test Case: | perf/compiler/T13035 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes I forgot to add a file; my fault. Thanks to Matthew for adding it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:38:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:38:47 -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.c2465a29633489a9c0b15b8338de7665@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha. Yes, `j2_sbYy` was born as a join-point but some subsequent transformation changed it into a non-join point. Happily [wiki:SequentCore Luke's work on join points] should nail this. I suggest you down-tools on this until Luke has his stuff committed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:38:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:38:58 -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.61a07e946ef4369a9db1593fce9888b2@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 09:55:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 09:55:33 -0000 Subject: [GHC] #13090: Expose all unfoldings of overloaded functions by default In-Reply-To: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> References: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> Message-ID: <064.9267e22f6ce2e0d60e6ae1d631252bb1@haskell.org> #13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not sure I agree with either * Users expect their overloaded functions to be specialised at call sites or * A more sensible default is to [copy the code of every overloaded function into every module which uses it once for every time at which it is used] I would be more worried about the effects on program size and compile time than on interface file size. Maybe instead an opt-in flag `-fexpose-all- overloaded-unfoldings`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 10:08:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 10:08:58 -0000 Subject: [GHC] #12908: Tuple constraints refactoring seems to regress performance considerably In-Reply-To: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> References: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> Message-ID: <061.2d96c861f73764cae5ba87bfdc9554b7@haskell.org> #12908: Tuple constraints refactoring seems to regress performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: performance 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): I would also be curious to see examples of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 10:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 10:18:28 -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.84ac15bf8eb888a36ba94bbed5a12632@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: maurerl@…, pdownen@…, ariola@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 10:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 10:41:27 -0000 Subject: [GHC] #13084: 'foreign import prim' are marked PlaySafe by the parser In-Reply-To: <048.4b89f1d732f141f887872f7aef28e459@haskell.org> References: <048.4b89f1d732f141f887872f7aef28e459@haskell.org> Message-ID: <063.0172313721b240ff6cd92962b50f1341@haskell.org> #13084: 'foreign import prim' are marked PlaySafe by the parser -------------------------------------+------------------------------------- Reporter: jberryman | 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 think that's a good question. Neither the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi- chap.html user manual section] nor the [wiki:Commentary/PrimOps wiki commentary] discuss the interaction of `foreign import prim` with GC. Indeed my assumption would have been that `foreign import prim` was by- default unsafe, i.e. should not trigger gc. I'd have thought it made sense to allow a safe/unsafe attribute on `foreign import prim`. Simon M: any thoughts? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 11:58:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 11:58:51 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.92468b8f01f84f103329c55bfdb60a13@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ohhellojoe): I found the flag via --supported-extensions. I was looking for a layout- related extension that would allow me to forgo indentation of a do block that is the last statement of another do block. It did the trick. Maybe there was a better, more commonly used extension that would have served. {{{#!hs foobar :: IO (Maybe ()) foobar = do putStrLn "doing stuff in IO monad" return $ do Just () -- not indented. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 12:28:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 12:28:31 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.051826a3d9d3fc93511ccd905e75308e@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): You're looking for `-XNondecreasingIndentation`: {{{ > t13087 cat test.hs {-# LANGUAGE LambdaCase #-} {-# LANGUAGE NondecreasingIndentation #-} isOne :: Int -> Bool isOne = \case 1 -> True _ -> False foobar :: IO (Maybe ()) foobar = do putStrLn "" return $ do Just () main = return () > t13087 ghc test.hs [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 12:44:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 12:44:53 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.cc6e79c772ea5134d396028768183c78@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: GHCi | 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 vanto): * status: closed => new * resolution: invalid => Comment: Thank you.[[BR]] Though your code in the answer is not adapted I agree with you. However the timing varies. Timing (and memory) is given roughly. If it is for educational purpose then why not, otherwise the result is wrong.[[BR]][[BR]] You know that time never varies in a computation into a CPU. It is impossible! Here is a function:[[BR]] {{{ fact :: Integer -> Integer fact n = if n==0 then 1 else n*fact(n-1) }}} {{{ let x = fact 123456 }}} In GHCi, the time to compute 10 times x is:[[BR]] {{{ 1) 55.10 secs, 21,427,209,296 bytes 2) 5.07 secs, 230,369,932 bytes 3) 5.05 secs, 230,369,932 bytes 4) 4.98 secs, 230,372,432 bytes 5) 4.59 secs, 230,367,100 bytes 6) 5.57 secs, 230,372,576 bytes 7) 5.58 secs, 230,368,404 bytes 8) 5.19 secs, 230,367,872 bytes 9) 5.37 secs, 230,372,576 bytes 10) 5.32 secs, 230,368,404 bytes }}} However as you can see, timing is not correct to return x. And is 55.10 secs a correct time? I say no. See evidence below. If I compute 10 times "fact 123456" I have:[[BR]] {{{ 1) 50.79 secs, 21,427,207,192 bytes 2) 49.66 secs, 21,427,207,840 bytes 3) 50.08 secs, 21,427,208,388 bytes 4) 49.23 secs, 21,427,206,484 bytes 5) 49.12 secs, 21,427,207,840 bytes 6) 48.58 secs, 21,427,207,788 bytes 7) 47.55 secs, 21,427,209,036 bytes 8) 47.66 secs, 21,427,206,536 bytes 9) 48.16 secs, 21,427,206,484 bytes 10) 46.88 secs, 21,427,208,984 bytes }}} Which is the real time? And if I compute 10 times "fact 12345" I have:[[BR]] {{{ 1) 0.80 secs, 172,989,980 bytes 2) 1.06 secs, 172,985,364 bytes 3) 0.89 secs, 172,986,620 bytes 4) 0.83 secs, 172,985,364 bytes 5) 0.86 secs, 172,984,624 bytes 6) 0.78 secs, 172,988,552 bytes 7) 0.81 secs, 172,986,924 bytes 8) 0.87 secs, 172,987,520 bytes 9) 1.08 secs, 172,985,728 bytes 10) 1.12 secs, 172,985,364 bytes }}} The timing varies. This is not correct. And as you can see, the amount of memory is not the same. In a Central Processing Unit (CPU) the activities are cyclical. The processor fetches an instruction, performs the operations required, fetches the next instruction, and so on.[[BR]] This orderly sequence of events requires a free running oscillator clock which furnishes the reference for all processor actions.[[BR]] The combined fetch and execution of a single instruction is referred to as an Instruction Cycle. The portion of a cycle identified with a clearly defined activity is called a State. And the interval between pulses of the timing oscillator is referred to as a Clock Period.[[BR]] As a general rule, one or more clock periods are necessary for the completion of a state, and there are several states in a cycle. For example, with Intel 8080A CPU, the instruction set "MOVr1,r2" which is "Move register to register" has 5 Clock Cycles, and the instruction set "INR M" which is "Increment memory" has 10 Clock Cycles.[[BR]][[BR]] Time never varies.[[BR]][[BR]] I think that the code which implements {{{:set +s}}} is to be rewritten if the values of time (and memory) are used for work otherwise it is acceptable, but it would be better to indicate it in the help of GHCi that the time is approximate and the memory also.[[BR]] What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 13:07:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 13:07:35 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.d3c5b4d68ac9e1e23985389e1a63c0a8@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 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 rwbarton): * status: new => closed * resolution: => invalid Comment: If you can figure out how to run ghci on a processor from 1974 then you might get consistent runtimes from ghci. With a modern preemptive- multitasking OS using virtual memory and running on a pipelining, branch- predicting processor with many levels of caching, where a memory read might cost 4 to 200 cycles depending what level of the cache it is in (or orders of magnitude more if it's swapped out to disk!), you cannot add up cycle counts like this any more. Unfortunately it does mean that there is a significant, effectively random component of program runtime; that's the cost of computers getting many thousands of times faster. Even your processor's clock rate is not constant any more. It's increased and decreased according to demand to save power when the processor is idle, or to avoid overheating. The numbers displayed by `:set +s` are the real times, and they are not fixed because the real times are not fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 13:47:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 13:47:43 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.05a1eca02b5b84a846cb62eab98c1c83@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible 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 simonpj): * owner: => goldfire Comment: Richard, `TcCanonical.zonk_eq_types` is completely broken. I don't quite know why it's there but it's utterly wrong. Consider the call `zonkEqTypes (T Par1) (S (Par1 b))`. Even though the head type constructors are utterly different you still use `tcRepSplitAppTy_maybe` to make recursive calls to {{{ go T S and go Par1 (Par1 b) }}} Notice these two arguments have different kinds. Incidentally it seems terribly inefficient to break into binary applications when both types are manifestly `TyConApp`s. Now the `tc1 == tc2` case of `go` kicks in, and we call `tycon`. Alas this calls `zipWithM` which simply discards the `b` argument to `Par1`. Eek. This mis-match kind stuff could occur, I guess, if you had {{{ go (T k1 t1) (T k2 t2) }}} where `T` is polykinded and `k1` differs from `k2`. So fixing the efficiency bug would not be enough to fix the mis-matched kind bug. I have a fix validating Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 14:58:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 14:58:51 -0000 Subject: [GHC] #13084: 'foreign import prim' are marked PlaySafe by the parser In-Reply-To: <048.4b89f1d732f141f887872f7aef28e459@haskell.org> References: <048.4b89f1d732f141f887872f7aef28e459@haskell.org> Message-ID: <063.129c81e17aae903cd335c8ac9c12b03e@haskell.org> #13084: 'foreign import prim' are marked PlaySafe by the parser -------------------------------------+------------------------------------- Reporter: jberryman | 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 jberryman): Sorry I think my description above was a little unclear; it ''does'' I think look like the generated code is just setting up the registers and doing a jump, which is what I was expecting/hoping (although maybe a GC is being triggered and I don't know what that looks like). It was suggested that this might be a "display bug" that might cause issues down the line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 14:59:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 14:59:00 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.c2d491b72e7dcedc0e6ab95ee000c84d@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible 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 Simon Peyton Jones ): In [changeset:"7d2e5da61714025142f0085d5ae150a61e637a5e/ghc" 7d2e5da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7d2e5da61714025142f0085d5ae150a61e637a5e" Fix zonk_eq_types in TcCanonical This fixes Trac #13083. An egregious bug. Merge to the 8.0 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 15:00:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 15:00:18 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.11b0a68f0c8ca17eacbc59a4425bad0e@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13083 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T13083 * milestone: => 8.0.3 Comment: Richard: pls check. Merge to 8.0 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 15:13:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 15:13:32 -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.a8536eecd6f89db196f9e9fb6f5b3fe0@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I have this nearly working following the the approach you outlined above, but there's one point I'm not sure about having to do with type family instance checking. Originally I had `Prelude` importing `GHC.LargeTuple`, but since `GHC.LargeTuple` defines type family instances (for `Rep`) it was marked as a "family instances" import of `Prelude`; which meant that any time the user loaded an interface file with their own type family instances, GHC would read the interface file for `GHC.LargeTuple` too to make sure there were no conflicts. Not good. So I figured out that `Prelude` doesn't actually need to import `GHC.LargeTuple`, since the type checker will load the latter when needed with `checkWiredInTyCon`. Now everything works great. However, I'm not sure about the type family soundness situation. Consider that a user can write an instance that overlaps with the ones from `GHC.LargeTuple` without mentioning a tuple, such as {{{#!hs instance Generic (a b c d e f g h i j k l m n o p q r s t) where type Rep (a b c d e f g h i j k l m n o p q r s t) = X -- overlaps with a 19-tuple. -- Can even replace `b` with a data type defined in this module, -- so it wouldn't be an orphan }}} I think it's still impossible to use both instances in the same program without mentioning a large tuple constructor and therefore loading the `GHC.LargeTuple` interface file and finding the conflict; but I'm not 100% sure (what if the uses of the two type family instances are in separate packages, etc.) Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 15:29:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 15:29:28 -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.edacd72270daa5ff62c3cde35a5247e7@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): > any time the user loaded an interface file with their own type family instances, GHC would read the interface file for GHC.LargeTuple too to make sure there were no conflicts I don't think so. If M contains a type family instance, that instance should have been checked for consistency with `LargeTuple`. See `FamInst`: {{{ Note [Checking family instance consistency] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For any two family instance modules that we import directly or indirectly, we check whether the instances in the two modules are consistent, *unless* we can be certain that the instances of the two modules have already been checked for consistency during the compilation of modules that we import. }}} So `M` and `LargeTuple` have already been checked; so importers of `M` won't need to check. Right? To be sure it's a bit of a pain having to load `LargeTuple` for `M`. But you suggested solution sounds ad-hoc and fragile to me. One possibility might be this: rather than a "family instance module" being a boolean flag, keep a list of the type functions it has instances of. Now if A defines instances of FA and B defines instances of FB we don't need to check them against each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 15:30:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 15:30:57 -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.aae11050cfb43ad5cdd403bff6064a65@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think I figured out the answer to my question. The reason why GHC needed to load the interface file for `GHC.LargeTuple` for family instance checking when `Prelude` imported it is because I might have written a function in `Prelude` that relies on the family instance. Since I actually didn't do that, it's fine to not eagerly check `GHC.LargeTuple` for type family instance conflicts when loading `Prelude`. Anyone who does use the `GHC.LargeTuple` type family instances (even indirectly through another module) will have `GHC.LargeTuple` as a "family instances" import of their module (worth actually testing!) and so the necessary consistency checks will be done when we import that module in another module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 15:32:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 15:32:01 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.650af92b848c7111fc26bcbe2df1f089@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: GHCi | 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 vanto): * status: closed => new * resolution: invalid => Comment: Be polite M. rwbarton.[[BR]] Instead of giving the time in seconds it is better to give it as a clock cycle.[[BR]] 8080 was an example to show clock cycles, because I know this processor. But I am aware of the latest technologies.[[BR]] What were you doing in the year of 1971?[[BR]] Me, I developed on this microprocessor, with instructions set. And you?[[BR]] If you hold the truth... ask the engineers at Intel Corp, please.[[BR]] Time never varies, because time are clock cycles and clock cycles do not varies.[[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 16:02:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 16:02:52 -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.4a4f3338b037e6e8dbbbf62c717da076@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): > I might have written a function in Prelude that relies on the family instance But that's true in every module. I don't understand. Are you proposing some kind of special case for `LargeTuple`? Or are you just saying that you were mistaken? Or what? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 16:24:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 16:24:51 -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.b927248dc18e9ff7fb9f20b1eff59dd8@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:6 simonpj]: > I don't think so. If M contains a type family instance, that instance should have been checked for consistency with `LargeTuple`. See `FamInst`: > {{{ > Note [Checking family instance consistency] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For any two family instance modules that we import directly or indirectly, we > check whether the instances in the two modules are consistent, *unless* we can > be certain that the instances of the two modules have already been checked for > consistency during the compilation of modules that we import. > }}} > So `M` and `LargeTuple` have already been checked; so importers of `M` won't need to check. Right? Interesting. If it's supposed to work this way in this scenario, it doesn't (and hasn't since 7.8.4 at least). Any user module that imports another user module that defines a type family instance forces reading the interface files in base that define type family instances. I'll take a closer look. > > I might have written a function in Prelude that relies on the family instance > > But that's true in every module. I don't understand. Are you proposing some kind of special case for LargeTuple? Or are you just saying that you were mistaken? Or what? Okay, let me step back a bit. Originally I added an `import GHC.LargeTuple ()` to Prelude because I thought it was necessary and sufficient for GHC to know about the instances (both type family and class instances) in `GHC.LargeTuple` in programs that import Prelude. It turned out to be neither sufficient, nor necessary. It was not sufficient because the type checker was just pulling the `TyCon` for a large tuple out of thin air, in `tcExpr`. So, writing a large tuple expression did not cause `GHC.LargeTuple` to be read, and so the instances were not available. Adding the `checkWiredInTyCon` call to `tcExpr` fixed that. In fact since GHC has wired-in knowledge that large tuples live in `GHC.LargeTuple`, the `checkWiredInTyCon` call makes it read the `GHC.LargeTuple` interface file, which is conveniently where the instances are as well. So, now the `import GHC.LargeTuple ()` in Prelude served no actual purpose. Its only apparent effect was to mark `GHC.LargeTuple` as a "family instances" import of Prelude. What I was arguing above is that receiving the type family instances for large tuples should not be thought of as an effect of importing Prelude. Rather, it is as though any module which mentions a large tuple implicitly has an `import GHC.LargeTuple` added. There's no more need for Prelude to export the large tuple instances than there is for it to export instances defined by any other module in base that Prelude does not import. It just feels a bit odd at first because it seems natural to think of the large tuples as being imported from Prelude, rather than another place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 16:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 16:29:43 -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.d9d329804c658dcc21d11ba081f520cf@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:9 rwbarton]: > Replying to [comment:6 simonpj]: > > So `M` and `LargeTuple` have already been checked; so importers of `M` won't need to check. Right? > > Interesting. If it's supposed to work this way in this scenario, it doesn't (and hasn't since 7.8.4 at least). Any user module that imports another user module that defines a type family instance forces reading the interface files in base that define type family instances. I'll take a closer look. {{{ How do we know which pairs of modules have already been checked? Any pair of modules where both modules occur in the `HscTypes.dep_finsts' set (of the `HscTypes.Dependencies') of one of our directly imported modules must have already been checked. Everything else, we check now. (So that we can be certain that the modules in our `HscTypes.dep_finsts' are consistent.) }}} Should we also be assuming that if module `A` is one of our directly imported modules and `A`'s `dep_finsts` are `[B,C,D]` that `A` has been checked against each of `B`, `C`, `D`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 17:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 17:16:54 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented In-Reply-To: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> References: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> Message-ID: <064.225437a2cc30663967958035477c9b6e@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | 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 mpickering): Yes that is right Dan. Is the compilation time much worse than marking all your definitions as `INLINABLE`? I can't see what it would do more than that would. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 18:37:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 18:37:38 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.95641ea846f19268d69995f720fcb566@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Great, thanks @refold, I'll take a look and let you know. I'm certainly planning on trying to get it into the tree. We can just branch it off for now. I want to use this as a basis for the other I/O changes in GHC. Would be a shame to let all this work go to waste :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 20:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 20:07:05 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.8820b0528d5f9e9cc400bacdb74ba3e3@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2940 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D2940 => Phab:D2940 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 21:34:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 21:34:59 -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.505234a19bc44378d5d0140dd91f6894@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): > Should we also be assuming that if module A is one of our directly imported modules and A's dep_finsts are [B,C,D] that A has been checked against each of B, C, D? Yes I think so. Otherwise compilation of A should fail! Make a test case and check that it really does! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 21:44:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 21:44:06 -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.625809e67628d4de10c635814cb5f29f@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:11 simonpj]: > > Should we also be assuming that if module A is one of our directly imported modules and A's dep_finsts are [B,C,D] that A has been checked against each of B, C, D? > > Yes I think so. Otherwise compilation of A should fail! Make a test case and check that it really does! It currently doesn't. I have a patch Phab:D2947 to fix this, but it needs to be cleaned up and a test added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 21:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 21:59:36 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 Message-ID: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: | Operating System: Solaris Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ===--- building phase 1 gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:584: compiler/stage1/build/.depend-v.haskell: No such file or directory "/opt/ghc-7.10.2-amd64/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all- packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.1.0-bcc57434d4c4ded429bd4c7561dc7931 -package-id containers-0.5.6.2-3bd9811190df2d727713a53a0942b5c9 -package-id directory-1.2.2.0-17006ecadb146c26f40f44f8704a6547 -package-id filepath-1.4.0.0-8fee9c13b5e42926cc01f6aa7c403c4b -package-id process-1.2.3.0-47082ea082854427d5ceb7c692692d3c -XHaskell2010 -no-user- package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -c utils/hsc2hs/./Main.hs -o utils/hsc2hs/dist/build/Main.o "/opt/ghc-7.10.2-amd64/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP- include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.1.0-bcc57434d4c4ded429bd4c7561dc7931 -package-id containers-0.5.6.2-3bd9811190df2d727713a53a0942b5c9 -package-id directory-1.2.2.0-17006ecadb146c26f40f44f8704a6547 -package-id filepath-1.4.0.0-8fee9c13b5e42926cc01f6aa7c403c4b -package-id process-1.2.3.0-47082ea082854427d5ceb7c692692d3c -XHaskell2010 -no-user- package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -optl-optl- Wl,-m64 -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.1.0-bcc57434d4c4ded429bd4c7561dc7931 -package-id containers-0.5.6.2-3bd9811190df2d727713a53a0942b5c9 -package-id directory-1.2.2.0-17006ecadb146c26f40f44f8704a6547 -package-id filepath-1.4.0.0-8fee9c13b5e42926cc01f6aa7c403c4b -package-id process-1.2.3.0-47082ea082854427d5ceb7c692692d3c -XHaskell2010 -no-user- package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Paths_hsc2hs.o ld: fatal: option '-optl-Wl,-m64' and option '-outils/hsc2hs/dist/build/tmp/hsc2hs' are multiple definitions collect2: error: ld returned 1 exit status gmake[1]: *** [utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1 gmake: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 23:28:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 23:28:49 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.01deb91b41ef3b9fddf60597183460f0@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej 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): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Lennart, do you think you could give a bit more info about why you need this, for documentation purposes if nothing else? Also, I'm curious whether we could ''lose'' anything by revealing that `Symbol` is anything more than ordered. I don't know of anything, but that doesn't mean there isn't anything. Finally, are there other operations on symbols that would be useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 23:29:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 23:29:39 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.72bb390f8687a61c3176361149e3bfed@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Compiler (Type checker) * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 9 23:47:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jan 2017 23:47:40 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic Message-ID: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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: -------------------------------------+------------------------------------- FamInst has this logic for checking type family instance consistency among imports: {{{ Note [Checking family instance consistency] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For any two family instance modules that we import directly or indirectly, we check whether the instances in the two modules are consistent, *unless* we can be certain that the instances of the two modules have already been checked for consistency during the compilation of modules that we import. [...] How do we know which pairs of modules have already been checked? Any pair of modules where both modules occur in the `HscTypes.dep_finsts' set (of the `HscTypes.Dependencies') of one of our directly imported modules must have already been checked. Everything else, we check now. (So that we can be certain that the modules in our `HscTypes.dep_finsts' are consistent.) }}} However, suppose one of the modules `A` we import directly is itself a type family instance module. Then it too has been checked for consistency with its dependencies `B`, `C`, etc., so we should skip checking the pairs `A` & `B`, `A` & `C`, etc. The current behavior means that whenever we directly import a type family instance module, we still have to load the interface files for all its type family module dependencies, which largely defeats the purpose of the optimization in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 00:41:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 00:41:58 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.dd919d749ac47678ad1067f68a5dd54a@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 rwbarton): Actually this is wrong! I managed to write `unsafeCoerce` in my compiler with this change. The reason is that type family instances defined in a module `A` are not actually checked for consistency with all its family instance dependencies `B`, `C`, ...; that seems to only happen when the interface file for (say) `B` is read for some other reason. I'm not sure yet whether that means even the existing consistency checks are inadequate; but it's at least surprising that you can write a module that has a type family instance that conflicts with an indirect dependency. Just to say it again explicitly, because it seems strange: when compiling a module containing a type family instance, GHC does not read all its indirect dependencies which have type family instances to ensure consistency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 00:49:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 00:49:47 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.c16ba83078600fca8b73666778ea8ac8@haskell.org> #8043: Feature Request : Qualified module exports -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 sseefried): Are people still interested in this feature? I for one would be very interested. Are there any great difficulties in implementing this feature that we should discuss here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 00:50:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 00:50:48 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.9e0ecaead5653a172529e971b950c0ba@haskell.org> #8043: Feature Request : Qualified module exports -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 sseefried): * cc: sean.seefried@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 01:14:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 01:14:38 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.835f0f911caa80d12fcabd49d7981e50@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 rwbarton): I managed to break type family consistency in 8.0.1 using `ghc -c` alone, but apparently it was in some way that fooled the recompilation checker and it can't be reproduced from a clean build. So I don't know how I did it. In any case, it seems more logical for the type family instances in `A` to be checked against `B` while compiling `A`, rather than forcing every importer of `A` to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 01:47:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 01:47:53 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.fbcfba17652414fc22d1531812761298@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 goldfire): This sounds terrible. Would you mind sharing your test files? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 01:50:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 01:50:14 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.3aecbc0d57cb6c38f2b0d9a56d286435@haskell.org> #8043: Feature Request : Qualified module exports -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 goldfire): Now that we have an [http://github.com/ghc-proposals/ghc-proposals official way to discuss] such proposals, this would make a nice candidate for such discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 01:52:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 01:52:01 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.0e130e25f8c2c731958c886db891d60e@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 02:21:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 02:21:05 -0000 Subject: [GHC] #13083: Constraint solving failure with Coercible + type family + newtype In-Reply-To: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> References: <044.96f11d58310ffada9b53e44f74b99001@haskell.org> Message-ID: <059.6b41b691109760222d3269f52fb501dd@haskell.org> #13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Coercible Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13083 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, looks good to me. Previous version was just wrong, as you discovered. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 02:24:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 02:24:34 -0000 Subject: [GHC] #13093: Runtime linker chokes on LLVM function on Windows Message-ID: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> #13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This error prevents the [http://hackage.haskell.org/package/llvm-general llvm-general] library from loading in GHCi on Windows. I don't know how to reproduce this error without using LLVM. First, you need to install LLVM. On Windows, you can install it with MSYS2: {{{ pacman -S mingw-w64-x86_64-llvm }}} Currently, this gives you LLVM-3.9, although I've reproduced it with LLVM-3.8 as well. Now define this Haskell file: {{{#!hs module Main (main) where import Foreign.C.Types newtype LLVMBool = LLVMBool CUInt deriving Show foreign import ccall unsafe "LLVMIsMultithreaded" isMultithreaded :: IO LLVMBool main :: IO () main = isMultithreaded >>= print }}} If you compile it, it works OK: {{{ $ ghc LLVM.hs -fforce-recomp $(llvm-config --libs) $(llvm-config --system- libs) -lstdc++-6 -lgcc_s_seh-1 [1 of 1] Compiling Main ( LLVM.hs, LLVM.o ) Linking LLVM.exe ... $ ./LLVM LLVMBool 1 }}} Or, if you're allergic to `llvm-config`: {{{ $ ghc LLVM.hs -fforce-recomp -lLLVMLTO -lLLVMObjCARCOpts -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoDWARF -lLLVMGlobalISel -lLLVMCoverage -lLLVMTableGen -lLLVMLineEditor -lLLVMOrcJIT -lLLVMMIRParser -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMObjectYAML -lLLVMLibDriver -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMPasses -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTransformUtils -lLLVMMC -lLLVMBitWriter -lLLVMBitReader -lLLVMAnalysis -lLLVMProfileData -lLLVMCore -lLLVMSupport -lpsapi -lshell32 -lole32 -luuid -lstdc++-6 -lgcc_s_seh-1 [1 of 1] Compiling Main ( LLVM.hs, LLVM.o ) Linking LLVM.exe ... $ ./LLVM LLVMBool 1 }}} If you load it into GHCi, however, things go awry: {{{ $ ghci $(llvm-config --libs) $(llvm-config --system-libs) -lgcc_s_seh-1 GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf Ok, modules loaded: Main (LLVM.o). > main ghc.exe: LLVM.o: unknown symbol `LLVMIsMultithreaded' }}} On GHC 8.0.1 and HEAD, it's a slightly different error: {{{ > main ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: LLVMIsMultithreaded This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 02:32:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 02:32:31 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.c3ac86382525454988bf11bc38fa4a61@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:46 mpickering]: Thanks for this detailed reply! I'm happy with all your responses save one: > > - The spec says "We verify that the result types of each constructor in a complete match agrees with each other." What does this sentence mean? Consider the possibility of pattern synonyms that match against functions, polymorphic patterns, and possibly even higher-rank patterns. > > > > It means that we look at the result type of each conlike and then verify that the type constructor for each type is the same. In the case of a set containing polymorphic patterns, at least one pattern in the set must have a definite type or you must specify a type signature to fix the type for the whole set. I'm not sure what you mean here. Where do you specify the type signature? In the `COMPLETE` pragma? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 02:53:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 02:53:58 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.e88baa7f02894b6cc51b8174dc25c5be@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Phab:D2931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record, I was never convinced that Simon's a0899b2... was a good idea. I think we went with it thinking "let's try and see what happens". And now we see what happens! I advocate for reverting that commit. Simon, the message says that it slows GHC down, but why? If the check is compiled by a sufficiently smart compiler, it shouldn't slow a thing down in the common case. Right after the `isTyVar` check (which should be inlined), we do a `tcTyVarDetails`. This requires case-splitting on the constructor for the `Var`. All we want to do is to replace the default error continuation in the non-`TcTyVar` case with something that returns `False`. Or is GHC not a sufficiently smart compiler? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 03:32:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 03:32:16 -0000 Subject: [GHC] #13093: Runtime linker chokes on LLVM function on Windows In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.4864bd507db0ecf668ef3b3ef13292c9@haskell.org> #13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's worth noting that this is a statically linked LLVM build, not a shared (dynamically linked) build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 04:51:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 04:51:55 -0000 Subject: [GHC] #13094: Poor register allocation and redundant moves when using `foreign import prim` Message-ID: <048.f20d5b598587307897dc5d81cca8cb87@haskell.org> #13094: Poor register allocation and redundant moves when using `foreign import prim` ----------------------------------------+--------------------------------- Reporter: jberryman | 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: #12232 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This may well be the same as #12232 but I didn't want to risk hijacking that one. I've been looking at the dumped asm from a library where I use `foreign import prim` to call a simple assembly routine (that may be irrelevant). I see many `movq` instructions, and when I traced them by hand many or most seemed superfluous saving and restoring of registers. Here is a contiguous and mostly self-contained snippet of the assembly, with notes. I have four values I'm interested in V0, V1, V2, V3 which I started tracing at the note "registers good for sipRound_s_x2 at this point". Below I specifically follow V3 through the assmebly, marking lines with {{{"*** V3 ***"}}}, and the moves don't seem sensible to my (untrained) eye: {{{ _c7Ns: movq %r9,%rbx movq %rax,%r9 movq %r8,%rax ; *** V3 *** movq %rbx,%r8 movq %rdi,%rbx movq %rax,%rdi ; *** V3 (back to rdi!) *** movq %rsi,%rax movq %rbx,%rsi movq %r14,%rbx movq %rax,%r14 movq %rcx,16(%rbp) addq $16,%rbp jmp *8(%rbp) .align 8 .quad 836 .quad 32 block_info: _c7Nk: movq 16(%rbp),%rax movq $8,16(%rbp) movq 24(%rbp),%rcx incq %rcx movq %rcx,24(%rbp) movq 32(%rbp),%rdx incq %rdx movq %rdx,32(%rbp) xorq 8(%rbp),%rbx addq $16,%rbp movl $8,%r8d xorl %r9d,%r9d _n7T1: movq %rax,64(%rsp) movq %r8,%rax ; --- registers good for sipRound_s_x2 at this point ------ movq %rdi,%r8 ; moving V3 *OUT* of rdi *** V3 *** movq %rsi,%rdi ; moving V2 *OUT* of rdi movq %r14,%rsi ; moving V1 *OUT* of r14 movq %rbx,%r14 ; moving V0 *OUT* of rbx movq 64(%rsp),%rbx _c7My: ; (NOTE: there are a few jumps to here from other sections not included here) cmpq 24(%rbx),%rdx je _c7Ns _c7Nr: movq 16(%rbx),%r10 movzbl (%r10,%rdx,1),%r10d cmpq $1,%rax jne _c7N9 _c7Nl: movq $block_info,-16(%rbp) shlq $8,%r9 orq %r10,%r9 ;----- at this point (name: register): V0: r14, V1: rsi, V2: rdi, V3: r8 movq %rdi,%rax ; save rdi, trying to be rsi movq %r8,%rdi ; prepared rdi(V3) *** V3 *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi ; prepared rsi(V2) movq %r14,%rax movq %rcx,%r14 ; prepared r14(V1) movq %rbx,%rcx movq %rax,%rbx ; prepared rbx(V0) movq %r9,-8(%rbp) movq %rcx,(%rbp) addq $-16,%rbp jmp sipRound_s_x2 .align 8 .quad 1733 .quad 32 block_info: _c7N2: movq 24(%rbp),%rax movq $7,24(%rbp) movq 32(%rbp),%rcx incq %rcx movq %rcx,32(%rbp) movq 40(%rbp),%rdx incq %rdx movq %rdx,40(%rbp) movq 16(%rbp),%r8 xorq 8(%rbp),%rbx addq $24,%rbp movl $7,%r9d _n7T2: movq %rax,64(%rsp) movq %r9,%rax movq %r8,%r9 movq %rdi,%r8 movq %rsi,%rdi movq %r14,%rsi movq %rbx,%r14 movq 64(%rsp),%rbx jmp _c7My _c7N9: cmpq $1,%rax jbe _c7N3 _c7MW: decq %rax movq %rax,(%rbp) incq %rcx movq %rcx,8(%rbp) incq %rdx movq %rdx,16(%rbp) shlq $8,%r9 orq %r10,%r9 jmp _c7My _c7N3: movq $block_info,-24(%rbp) movq %rdi,%rax movq %r8,%rdi ; *** V3 (back to rdi!) *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi movq %r14,%rax movq %rcx,%r14 movq %rbx,%rcx movq %rax,%rbx movq %r9,-16(%rbp) movq %r10,-8(%rbp) movq %rcx,(%rbp) addq $-24,%rbp jmp sipRound_s_x2 .size $whashRemainingBytes_info, .-$whashRemainingBytes_info }}} This is my first time looking closely at assembly, so maybe this is normal or no big deal performance-wise (I haven't gotten around to trying to correlate number of moves with performance of my variations yet), or I'm missing something obvious. I wasn't able to make sense of an objdump-ed version of the llvm-compiled program. The code for the version where the same {{{sipRound}}} stuff is implemented in normal haskell also has a lot of moves (even more in fact), but they seem interspersed throughout and are less easy to sort through, e.g. a random snippet: {{{ xorq %rdi,%r8 movq %r14,%rdi shrq $32,%rdi shlq $32,%r14 orq %rdi,%r14 addq %r8,%r14 movq %r14,%rdi addq %rsi,%rdi movq %rsi,%r10 shrq $51,%r10 shlq $13,%rsi orq %r10,%rsi xorq %rdi,%rsi movq %r8,%r10 shrq $43,%r10 shlq $21,%r8 orq %r10,%r8 xorq %r14,%r8 movq %rax,%r10 shrq $32,%r10 shlq $32,%rax orq %r10,%rax addq %r8,%rax movq %rax,%r10 }}} Intuitively this is also bad, after all the haskell we're compiling looks almost trivially like the good assembly we'd like/expect (although perhaps {{{rotl}}} is shaking things up here, as we have to implement it with two shifts and an OR): {{{#!hs -- in the Identity monad do v0 <- return $ v0 + v1 v1 <- return $ rotl v1 13 v1 <- return $ v1 `xor` v0 v0 <- return $ rotl v0 32 v2 <- return $ v2 + v3 v3 <- return $ rotl v3 16 v3 <- return $ v3 `xor` v2 v0 <- return $ v0 + v3 v3 <- return $ rotl v3 21 v3 <- return $ v3 `xor` v0 }}} You can check out the branch here, which I'll keep at 838b27a: https://github.com/jberryman/hashabler/tree/saved-branch-exhibiting- seemingly-bad-register-allocation You can build and observe the assembly with: {{{ $ cabal configure -fdev --enable-benchmarks && cabal build core $ gvim ./dist/build/core/core-tmp/core.dump-asm }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 04:59:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 04:59:20 -0000 Subject: [GHC] #13094: Poor register allocation and redundant moves when using `foreign import prim` In-Reply-To: <048.f20d5b598587307897dc5d81cca8cb87@haskell.org> References: <048.f20d5b598587307897dc5d81cca8cb87@haskell.org> Message-ID: <063.353b29292c4e4225e5fb4bdab49c8408@haskell.org> #13094: Poor register allocation and redundant moves when using `foreign import prim` ---------------------------------+---------------------------------------- Reporter: jberryman | Owner: 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: #12232 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by jberryman: @@ -18,1 +18,1 @@ - {{{ + {{{#!gas New description: This may well be the same as #12232 but I didn't want to risk hijacking that one. I've been looking at the dumped asm from a library where I use `foreign import prim` to call a simple assembly routine (that may be irrelevant). I see many `movq` instructions, and when I traced them by hand many or most seemed superfluous saving and restoring of registers. Here is a contiguous and mostly self-contained snippet of the assembly, with notes. I have four values I'm interested in V0, V1, V2, V3 which I started tracing at the note "registers good for sipRound_s_x2 at this point". Below I specifically follow V3 through the assmebly, marking lines with {{{"*** V3 ***"}}}, and the moves don't seem sensible to my (untrained) eye: {{{#!gas _c7Ns: movq %r9,%rbx movq %rax,%r9 movq %r8,%rax ; *** V3 *** movq %rbx,%r8 movq %rdi,%rbx movq %rax,%rdi ; *** V3 (back to rdi!) *** movq %rsi,%rax movq %rbx,%rsi movq %r14,%rbx movq %rax,%r14 movq %rcx,16(%rbp) addq $16,%rbp jmp *8(%rbp) .align 8 .quad 836 .quad 32 block_info: _c7Nk: movq 16(%rbp),%rax movq $8,16(%rbp) movq 24(%rbp),%rcx incq %rcx movq %rcx,24(%rbp) movq 32(%rbp),%rdx incq %rdx movq %rdx,32(%rbp) xorq 8(%rbp),%rbx addq $16,%rbp movl $8,%r8d xorl %r9d,%r9d _n7T1: movq %rax,64(%rsp) movq %r8,%rax ; --- registers good for sipRound_s_x2 at this point ------ movq %rdi,%r8 ; moving V3 *OUT* of rdi *** V3 *** movq %rsi,%rdi ; moving V2 *OUT* of rdi movq %r14,%rsi ; moving V1 *OUT* of r14 movq %rbx,%r14 ; moving V0 *OUT* of rbx movq 64(%rsp),%rbx _c7My: ; (NOTE: there are a few jumps to here from other sections not included here) cmpq 24(%rbx),%rdx je _c7Ns _c7Nr: movq 16(%rbx),%r10 movzbl (%r10,%rdx,1),%r10d cmpq $1,%rax jne _c7N9 _c7Nl: movq $block_info,-16(%rbp) shlq $8,%r9 orq %r10,%r9 ;----- at this point (name: register): V0: r14, V1: rsi, V2: rdi, V3: r8 movq %rdi,%rax ; save rdi, trying to be rsi movq %r8,%rdi ; prepared rdi(V3) *** V3 *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi ; prepared rsi(V2) movq %r14,%rax movq %rcx,%r14 ; prepared r14(V1) movq %rbx,%rcx movq %rax,%rbx ; prepared rbx(V0) movq %r9,-8(%rbp) movq %rcx,(%rbp) addq $-16,%rbp jmp sipRound_s_x2 .align 8 .quad 1733 .quad 32 block_info: _c7N2: movq 24(%rbp),%rax movq $7,24(%rbp) movq 32(%rbp),%rcx incq %rcx movq %rcx,32(%rbp) movq 40(%rbp),%rdx incq %rdx movq %rdx,40(%rbp) movq 16(%rbp),%r8 xorq 8(%rbp),%rbx addq $24,%rbp movl $7,%r9d _n7T2: movq %rax,64(%rsp) movq %r9,%rax movq %r8,%r9 movq %rdi,%r8 movq %rsi,%rdi movq %r14,%rsi movq %rbx,%r14 movq 64(%rsp),%rbx jmp _c7My _c7N9: cmpq $1,%rax jbe _c7N3 _c7MW: decq %rax movq %rax,(%rbp) incq %rcx movq %rcx,8(%rbp) incq %rdx movq %rdx,16(%rbp) shlq $8,%r9 orq %r10,%r9 jmp _c7My _c7N3: movq $block_info,-24(%rbp) movq %rdi,%rax movq %r8,%rdi ; *** V3 (back to rdi!) *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi movq %r14,%rax movq %rcx,%r14 movq %rbx,%rcx movq %rax,%rbx movq %r9,-16(%rbp) movq %r10,-8(%rbp) movq %rcx,(%rbp) addq $-24,%rbp jmp sipRound_s_x2 .size $whashRemainingBytes_info, .-$whashRemainingBytes_info }}} This is my first time looking closely at assembly, so maybe this is normal or no big deal performance-wise (I haven't gotten around to trying to correlate number of moves with performance of my variations yet), or I'm missing something obvious. I wasn't able to make sense of an objdump-ed version of the llvm-compiled program. The code for the version where the same {{{sipRound}}} stuff is implemented in normal haskell also has a lot of moves (even more in fact), but they seem interspersed throughout and are less easy to sort through, e.g. a random snippet: {{{ xorq %rdi,%r8 movq %r14,%rdi shrq $32,%rdi shlq $32,%r14 orq %rdi,%r14 addq %r8,%r14 movq %r14,%rdi addq %rsi,%rdi movq %rsi,%r10 shrq $51,%r10 shlq $13,%rsi orq %r10,%rsi xorq %rdi,%rsi movq %r8,%r10 shrq $43,%r10 shlq $21,%r8 orq %r10,%r8 xorq %r14,%r8 movq %rax,%r10 shrq $32,%r10 shlq $32,%rax orq %r10,%rax addq %r8,%rax movq %rax,%r10 }}} Intuitively this is also bad, after all the haskell we're compiling looks almost trivially like the good assembly we'd like/expect (although perhaps {{{rotl}}} is shaking things up here, as we have to implement it with two shifts and an OR): {{{#!hs -- in the Identity monad do v0 <- return $ v0 + v1 v1 <- return $ rotl v1 13 v1 <- return $ v1 `xor` v0 v0 <- return $ rotl v0 32 v2 <- return $ v2 + v3 v3 <- return $ rotl v3 16 v3 <- return $ v3 `xor` v2 v0 <- return $ v0 + v3 v3 <- return $ rotl v3 21 v3 <- return $ v3 `xor` v0 }}} You can check out the branch here, which I'll keep at 838b27a: https://github.com/jberryman/hashabler/tree/saved-branch-exhibiting- seemingly-bad-register-allocation You can build and observe the assembly with: {{{ $ cabal configure -fdev --enable-benchmarks && cabal build core $ gvim ./dist/build/core/core-tmp/core.dump-asm }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 05:03:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 05:03:13 -0000 Subject: [GHC] #12232: Opportunity to do better in register allocations In-Reply-To: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> References: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> Message-ID: <062.9fab55a076ed680675e1e5487a4109c3@haskell.org> #12232: Opportunity to do better in register allocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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: #12231 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): I just added a similar (I think) issue: #13094 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 05:54:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 05:54:31 -0000 Subject: [GHC] #13095: Remove deprecated InteractiveEval API Message-ID: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> #13095: Remove deprecated InteractiveEval API -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: 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: -------------------------------------+------------------------------------- `RunResult(..)`, `runStmt`, and `runStmtWithLocation` were all deprecated in cf7573b8207bbb17c58612f3345e0b17d74cfb58, replaced by functions able to give more precise allocation statistics. Comments document them as slated for removal in 7.14. As I calculate it, 7.14=8.2, so the time has come. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 05:55:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 05:55:55 -0000 Subject: [GHC] #13095: Remove deprecated InteractiveEval API In-Reply-To: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> References: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> Message-ID: <060.b541dbcdc012642bf7e8e362de178314@haskell.org> #13095: Remove deprecated InteractiveEval API -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => dfeuer * differential: => Phab:D2949 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 06:31:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 06:31:22 -0000 Subject: [GHC] #10933: REMOVED pragma In-Reply-To: <047.034826e24c434b8ddb0afbdd6905b9d3@haskell.org> References: <047.034826e24c434b8ddb0afbdd6905b9d3@haskell.org> Message-ID: <062.f4c33e68001719bc25841a3aac892e07@haskell.org> #10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 06:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 06:39:55 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.577d9dea63f1d00123136a13f7519158@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 lukemaurer): This seems to have gone away; AFAICT, nowadays the join point is never created. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 06:56:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 06:56:24 -0000 Subject: [GHC] #13096: Remove tyConString Message-ID: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> #13096: Remove tyConString -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.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: -------------------------------------+------------------------------------- `Data.Typeable.tyConString` has been deprecated since GHC 7.4. We are long past the three-release rule, so it's time to remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 06:58:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 06:58:13 -0000 Subject: [GHC] #13096: Remove tyConString In-Reply-To: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> References: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> Message-ID: <060.1c18a01e7c16e3fe67ff656c612a57a3@haskell.org> #13096: Remove tyConString -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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:D2950 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D2950 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 06:59:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 06:59:15 -0000 Subject: [GHC] #13095: Remove deprecated InteractiveEval API In-Reply-To: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> References: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> Message-ID: <060.fddec229ca58b0663ac26a0d774d4afe@haskell.org> #13095: Remove deprecated InteractiveEval API -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | 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:D2949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 07:12:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 07:12:43 -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.0deda9f7d9b88878620264dd1332acd5@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): Looks to me like Simon's instinct was correct. Every instance of `$j1` remains a join point now, since those pesky contexts that were getting put around the calls are getting put into `$j1` instead. In fact, `k-nucleotide` is one of the poster children for join points—it gets an 86.0% decrease in allocs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 08:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 08:09:47 -0000 Subject: [GHC] #13097: Num a => Num (Down a) Message-ID: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Let's us write {{{#!hs >>> deriving instance Num a => Num (Down a) >>> (<) 10 20 True >>> (<) @(Down _) 10 20 False }}} With #12363 {{{#!hs >>> 10 < @(Down _) 20 False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 08:12:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 08:12:51 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.aad5b58786c1dce3ad8c74a34cf4d1ac@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): With #13097 {{{#!hs >>> 10 < 20 True >>> 10 < @(Down _) 20 False >>> 10 < @(Down (Down _)) 20 True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:04:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:04:21 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.4329c0cd6dcc6b0e645904266fdffe68@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Is this a feature request to add a `Num` instance for `Down`? It would be very helpful if you explained this on the ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:14:37 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.d2e71d01fd1b31e89ad484323f07d4c0@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | 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:D1940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by magesh.b): Is possible to extend this feature to support generating COMPLETE pragma #8779, if #8779 is going to land in 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:16:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:16:07 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.69de7b843451d484f0812bf5905bc156@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | 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:D1940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Please open a new ticket and assign me to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:30:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:30:44 -0000 Subject: [GHC] #13098: Template Haskell support for Pattern Synonym's Complete Pragma Message-ID: <047.5c7bf2bbd6e375ea42b9abcc915a892d@haskell.org> #13098: Template Haskell support for Pattern Synonym's Complete Pragma -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: mpickering 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: -------------------------------------+------------------------------------- #8779 provides exhaustive checking support for Pattern Synonym via Complete pragma. https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs It would be nice, if we are able to generate those pragma via TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:30:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:30:55 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.d1aa180ebf0b1bdb67d738b60013511c@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -1,1 +1,2 @@ - Let's us write + There are many missing instances for `Down`, I happened to need `Num (Down + _)`. It can be derived with GND: @@ -4,1 +5,2 @@ - >>> deriving instance Num a => Num (Down a) + newtype Down a = Down a deriving (Eq, Show, Read, Num) + }}} @@ -6,0 +8,3 @@ + which let's us write + + {{{#!hs @@ -12,0 +17,6 @@ + + We can of course add instances for `Functor`, `Applicative`, `Monad`, + `MonadFix`, ... I don't know that they would ever get but it wouldn't be + much trouble copying `Identity`, `Dual` instances. + + ---- New description: There are many missing instances for `Down`, I happened to need `Num (Down _)`. It can be derived with GND: {{{#!hs newtype Down a = Down a deriving (Eq, Show, Read, Num) }}} which let's us write {{{#!hs >>> (<) 10 20 True >>> (<) @(Down _) 10 20 False }}} We can of course add instances for `Functor`, `Applicative`, `Monad`, `MonadFix`, ... I don't know that they would ever get but it wouldn't be much trouble copying `Identity`, `Dual` instances. ---- With #12363 {{{#!hs >>> 10 < @(Down _) 20 False }}} -- Comment (by Iceland_jack): Replying to [comment:1 mpickering]: > Is this a feature request to add a `Num` instance for `Down`? It would be very helpful if you explained this on the ticket! Yes, along with other instances — changed description. What is the stance of ''base'', do we provide every instance that makes sense or limit it to instances we know have a use? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:32:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:32:36 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.1c4c61d5db723f1adb7333cf57daafc8@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -26,1 +26,0 @@ - @@ -31,0 +30,8 @@ + + with #12363 + #12465 + + + {{{#!hs + >>> 10 < @Down{} 20 + False + }}} New description: There are many missing instances for `Down`, I happened to need `Num (Down _)`. It can be derived with GND: {{{#!hs newtype Down a = Down a deriving (Eq, Show, Read, Num) }}} which let's us write {{{#!hs >>> (<) 10 20 True >>> (<) @(Down _) 10 20 False }}} We can of course add instances for `Functor`, `Applicative`, `Monad`, `MonadFix`, ... I don't know that they would ever get but it wouldn't be much trouble copying `Identity`, `Dual` instances. ---- With #12363 {{{#!hs >>> 10 < @(Down _) 20 False }}} with #12363 + #12465 {{{#!hs >>> 10 < @Down{} 20 False }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:33:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:33:53 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.c51255480da18cafb091ae82150d156a@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -19,2 +19,2 @@ - `MonadFix`, ... I don't know that they would ever get but it wouldn't be - much trouble copying `Identity`, `Dual` instances. + `MonadFix`, ... I don't know that they would see use but we can use + `Identity`, `Dual` instances. New description: There are many missing instances for `Down`, I happened to need `Num (Down _)`. It can be derived with GND: {{{#!hs newtype Down a = Down a deriving (Eq, Show, Read, Num) }}} which let's us write {{{#!hs >>> (<) 10 20 True >>> (<) @(Down _) 10 20 False }}} We can of course add instances for `Functor`, `Applicative`, `Monad`, `MonadFix`, ... I don't know that they would see use but we can use `Identity`, `Dual` instances. ---- With #12363 {{{#!hs >>> 10 < @(Down _) 20 False }}} with #12363 + #12465 {{{#!hs >>> 10 < @Down{} 20 False }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:44:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:44:15 -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.8a2277829bec05bc15d62da500a75225@haskell.org> #13098: Template Haskell support for Pattern Synonym's Complete Pragma -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * version: 8.0.1 => * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 10:44:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 10:44:35 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.ff73acb48ce2e5e9a84fb33c52fc831a@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): Actually there is ''some'' justification for the status quo. Here it is: * If A imports B, and A has `type instance F Int = Bool` and B has `type instance F Int = Char`, then any attempt to use `F Int`, in A or in any module A imports, will get a "overlapping instance" error on lookup. I think. So the conflict would be reported, but lazily. * In contrast, if A imports B and C, and B and C have those instance declarations, then compiling A might never need to reduce `F Int`, so we must eagerly check for consistency. I'm intrigued about how you managed to write `unsafeCoerce`. But regardless, I think it'd be better and more consistent to eagerly check consistency of all the new family instances in A with all those in modules it imports. Then instance lookup should never find more than one match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 11:03:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 11:03:13 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.8eba438db67c2599bd0697a246b62fba@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest 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 lwm): Oh, that is awesome phadej, well done! Yes, would be nice for it to be stand alone from base. I'll try and get a doctest run on my local with your Gist ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 11:05:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 11:05:37 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.c790b5ef4a4bdf9dbcf2d64d480aedb4@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Here are some examples that are actually useful, used with a non-standard version of [https://github.com/ekmett/hask/ hask]: {{{#!hs type Fix f = (f -> f) -> f newtype Mu1 :: Fix Type where In1 :: f (Mu1 f) -> Mu1 f newtype Mu2 :: Fix (k -> Type) where In2 :: f (Mu2 f) a -> Mu2 f a }}} If you want to reference the kind variable `k` you can write {{{#!hs -- instance Functor (Mu :: ((k -> Type) -> (k -> Type)) -> (k -> Type)) where instance Functor (Mu @k) where type Dom (Mu @k) = ... type Cod (Mu @k) = ... }}} instead of {{{#!hs instance Functor (Mu :: Fix (k -> Type)) where type Dom (Mu :: Fix (k -> Type)) = (Void :: Cat ((k -> Type) -> (k -> Type))) type Cod (Mu :: Fix (k -> Type)) = (Void :: Cat (k -> Type)) }}} ---- {{{#!hs instance Functor (Const @k a) where type Dom (Const @k a) = UNIT type Cod (Const @k a) = (->) fmap :: UNIT b b' -> (Const a b -> Const a b') fmap UNIT (Const a) = Const a }}} instead of {{{#!hs instance Functor (Const a :: k -> Type) where type Dom (Const a :: k -> Type) = UNIT type Cod (Const a :: k -> Type) = (->) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 11:17:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 11:17:10 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.56fdfcc10c113e63b21978798a83375f@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): We can rewrite {{{#!hs type Typeable1 (a :: Type -> Type) = Typeable a type Typeable2 (a :: Type -> Type -> Type) = Typeable a type Typeable3 (a :: Type -> Type -> Type -> Type) = Typeable a ... }}} as the more natural {{{#!hs type Typeable1 = Typeable @(Type -> Type) type Typeable2 = Typeable @(Type -> Type -> Type) type Typeable3 = Typeable @(Type -> Type -> Type -> Type) ... }}} which is how it appears in > {{{#!hs > type Typeable1 = Typeable @(* -> *) > }}} > — ExplicitTypeApplication#Typekindinstantiationinclasses -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 11:33:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 11:33:01 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.a1553d73c6656d4a12d5290b9ba02474@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: akio Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * owner: => akio * component: Compiler => libraries/base * differential: => Phab:D2951 * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 11:33:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 11:33:17 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.f09cd5a97cf32b87f67be3195ebfb11e@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't know if it's the sheer number of updates to this ticket, but this syntax is starting to look fairly natural to me. Most of these examples don't look like code I would ever write, but the {{{`catch` @IOException}}} example is pretty sweet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:13:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:13:53 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.70a17a19965e276f0b4f4438359f9728@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 rwbarton): I managed to write `unsafeCoerce` in 8.0.1 without involving recompilation tricks. Compile these modules in order with `ghc -c -XTypeFamilies -fforce-recomp` (then you can do a final link with `ghc -o Main Main.hs -XTypeFamilies`): {{{#!hs module A where type family A a }}} {{{#!hs module B (A, X) where import A data X type instance A (X, b) = () }}} {{{#!hs {-# LANGUAGE RankNTypes #-} module C (x) where import Data.Proxy import B x :: Proxy b -> (forall t. Proxy t -> Bool -> A (t, b)) -> (Bool -> ()) x _ f = f (undefined :: Proxy X) }}} {{{#!hs module Main where import Data.Proxy import A import C data Y type instance A (a, Y) = Bool y :: Proxy a -> Bool -> A (a, Y) y _ = id z :: Bool -> () z = x (undefined :: Proxy Y) y main = print (z True) }}} `Main` has been rigged to not directly mention any names defined in `B`, by creating the intermediate module `C`. When `Main` is compiled the interface file for `B` is not read at all! There is a kind of off-by-one error in the check. The logic in the Note `[Checking family instance consistency]` correctly takes into account the fact that we do not check consistency of family instances in a module with those in its `dep_finsts`, and so if you try to import `Main` in another module (even one that is otherwise empty) GHC will report the overlap. But that still leaves a window of one module in which the overlap can be exploited. Even if not for this example I agree with > But regardless, I think it'd be better and more consistent to eagerly check consistency of all the new family instances in A with all those in modules it imports. Then instance lookup should never find more than one match. I think it's even more efficient overall, since we currently do those checks in the importers of `A` instead, which usually will be at least one module. If we do them while compiling `A` then the optimization that this ticket was originally about will be sound and we can avoid the checks in the importers. I also figured out what my example involving recompilation was, I'll file a separate ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:27:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:27:14 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency Message-ID: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Suppose I have two modules `I1` and `I2` that define instances for the same type family and I have a module `M` consisting solely of {{{#!hs module M where import I1 import I2 }}} When GHC compiles `M` it checks that the type family instances of `I1` are consistent with those from `I2`. Then it writes out `M.hi` which is treated as a certificate that the type family instances of `I1` and `I2` are compatible: {{{ How do we know which pairs of modules have already been checked? Any pair of modules where both modules occur in the `HscTypes.dep_finsts' set (of the `HscTypes.Dependencies') of one of our directly imported modules must have already been checked. Everything else, we check now. (So that we can be certain that the modules in our `HscTypes.dep_finsts' are consistent.) }}} That means in particular that another module that imports `M` doesn't have to check family instance consistency between `I1` and `I2`. (Imagine `I1` and `I2` are two internal modules of a library and `M` is its top-level interface that just re-exports things.) Now suppose I edit `I2` in a way that makes its type family instances no longer consistent with those of `I1`, then recompile `I2` and then `M` in one-shot mode. Since `M` did not really use anything from `I2`, ghc concludes that recompilation of `M` is not required. But now the `M.hi` file is incorrect as a certificate that `I1` and `I2` have consistent instances and a consumer of `M` would be able to see the inconsistency even if it uses parts of `I1` and `I2` that changed. Two possible ways to address this: 1. Since `M.hi` represents a certificate of consistency between `I1` and `I2`, `M` should be considered to "use" the family instances so that it is recompiled when the instances change. 2. When determining which pairs of modules we don't need to check for consistency in FamInst, we take some interface hash into account to make sure that the versions of (in this case) `I1` and `I2` that were checked for consistency when we compiled `M` are the same ones that we are importing in our client of `M`. I think we might want both of these, but especially the second one. This might ideally involve adding a "type family instances hash" to the interface file if it doesn't already exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:27:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:27:28 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.8714cc0859aa8efca4cb1561b8d4f176@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 rwbarton): See #13099 for the recompilation issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:34:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:34:34 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.7e43b992a22b672c9c14b07f3ca490f0@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): > When Main is compiled the interface file for B is not read at all! Ah, that is the bit I was missing! (It's not read, because nobody mentions `X`.) If B.hi was read we would (I hope) get an overlap error when solving `(A (a,y))`. Well done! In fixing this, do give a careful account of the invariants etc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:36:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:36:00 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.0f77073868e158a0a44bf6bab7f07ca9@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm inclined to (1). It's simple, and its consistent with our current story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:45:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:45:05 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.bed51c414e0a4676000e22edc3dbad2a@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 rwbarton): Replying to [comment:8 simonpj]: > > When Main is compiled the interface file for B is not read at all! > > Ah, that is the bit I was missing! (It's not read, because nobody mentions `X`.) If B.hi was read we would (I hope) get an overlap error when solving `(A (a,y))`. Earlier I had a simpler version (without the proxy/CPS stuff in `x` and `y`, and using visible type application in `z`) that ''was'' reading `B.hi`, because the type of `x` was `A (X, b) -> ()` which mentions `X`, which is defined in `B`. But it didn't read it until it got to `z`, at which point it had already type checked `y`, it seems. So it never noticed the conflict. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 12:53:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 12:53:15 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.c5fc6513988ef2d75391613dc03e829c@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Phab:D2931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I have worked it out. We use `tyCoVarsOfType`, `tyCoVarsOfCt` etc to extract the free type variables of a type or constraint. We don't have functions `tyVarsOfType` etc; they would be simple to write, but we don't have them. That means that we may get unwanted coercion variables floating around in the result set. This is annoying, and one alternative would be to add a family of functions returning tyvars. But returning the coercion variables (which appear in casts in types) actually causes no trouble ''provided all the "is" functions return False for coercion variables''. For example, {{{ promoteTyVar tclvl tv | isFloatedTouchableMetaTyVar tclvl tv = ... | otherwise = return () }}} Here `tv` might be a coercion variable, but it'll be ignored provided `isFloatedTouchableMetaTyVar` ignores it. So I'm ok with revering the patch, but please can we add a big Note with those functions explaining why coercion variables can occur is happening? Incidentally, in `TcSimplify` we have this: {{{ ; let meta_tvs = filter (isTyVar <&&> isMetaTyVar) free_tvs ... -- The isTyVar needs to weed out coercion variables }}} Once `isMetaTyVar` filters out coercion variables, we can remove the `isTyVar` here. Reid: over to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 13:03:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 13:03:25 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.ea19f63216bcc1baa22ecbc5cac98fed@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: GHCi | 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 vanto): I would like to say a precision to avoid all confusions. I think it is a matter of importance. There is a difference between the frequency of the microprocessor and the clock cycles of an instruction set from the processor.[[BR]] Somebody said that real times are not fixed. Well, that is the problem. We speak about time, we speak about Physics. The time of which you speak is a relative (real) time. With this time you can't do a comparison of values because, as you say, it is not fixed. We need a referential to something. And something is the clock cycles of instruction set. The clock cycles of an instruction set from the CPU nevers varies. You can have 2GHz CPU or 3GHz CPU, clock cycles never varies. [[BR]] Suppose you have an instruction set MOVX,X which move register from register in a core i7 CPU and takes 5 clock cycles. With 2Ghz CPU or with 3GHz CPU MOVX,X will always keep 5 clock cycles. The difference is in the speed of the processor. Do you understand this?[[BR]] If you compute starting from that you have a true time and you can make comparison with another values. [[BR]] Thus currently the number displayed by :set +s is a relative time which is useless, and the code which implements this is to be rewritten.[[BR]] Of course you can keep the code such as and not change it if it is appropriate to you. But I invite you to consider that.[[BR]] When some people are disturbed by something they don't know, they quickly close tickets. Let others give their opinions, please.[[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 13:17:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 13:17:51 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.7abb711fef70b7cd76c45aa2be8252a4@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:15 rwbarton]: > I don't know if it's the sheer number of updates to this ticket, but this syntax is starting to look fairly natural to me. Just According to Keikaku.⁽¹⁾ ⁽¹⁾ [https://www.reddit.com/r/OutOfTheLoop/comments/467byi/what_the_hell_is_keikaku/ (Translator's note: keikaku means plan)] > Most of these examples don't look like code I would ever write, but the {{{`catch` @IOException}}} example is pretty sweet. It works especially well with operators where the specified type does not appear in the return type: having to privilege one side over the other feels asymmetric, the [https://hackage.haskell.org/package/intervals intervals] package documentation gives a lot of good examples where this is useful: {{{#!hs -- >>> (5 ... 10 :: Interval Double) >> (5 ... 0) >> (20 ... 40 :: Interval Double) `contains` (15 ... 35 :: Interval Double) -- False >>> (20 ... 40) `contains` @Double (15 ... 35) False }}} but also simpler examples, I will avoid writing an explicit annotation if I can {{{#!hs -- >>> (0.1 :: Float) + 0.2 == 0.3 -- True >>> 0.1 + 0.2 == @Float 0.3 True -- >>> 0.1 + 0.2 == (0.3 :: Double) -- False >>> 0.1 + 0.2 == @Double 0.3 False -- >>> 0 `elem` [1,2::Int,3] -- False >>> 0 `elem` @[] @Int [1,2,3] False }}} For most examples you can easily annotate some other part of the expression to get the same effect. My experience is that infix type application leads to less thinking, more consistency (in where the type goes) and more resistance to change: I prefer the uncommented versions {{{#!hs -- n `hashWithSalt` (fromIntegral (ptrToIntPtr s) :: Int) -- n `hashWithSalt` fromIntegral @_ @Int (ptrToIntPtr s) n `hashWithSalt` @Int fromIntegral (ptrToIntPtr s) }}} {{{#!hs -- Var a -> digest c (1 :: Word8) `digest` a -- App f x -> digest c (2 :: Word8) `digest` f `digest` x -- HardType h -> digest c (3 :: Word8) `digest` h -- Forall k tvs cs b -> digest c (4 :: Word8) `digest` k `digest` tvs `digest` cs `digest` b -- Loc _ ty -> digest c ty -- Exists k tvs cs -> digest c (5 :: Word8) `digest` k `digest` tvs `digest` cs -- And xs -> digest c (6 :: Word8) `digest` xs Var a -> c `digest` @Word8 1 `digest` a App f x -> c `digest` @Word8 2 `digest` f `digest` x HardType h -> c `digest` @Word8 3 `digest` h Forall k tvs cs b -> c `digest` @Word8 4 `digest` k `digest` tvs `digest` cs `digest` b Loc _ ty -> c `digest` ty Exists k tvs cs -> c `digest` @Word8 5 `digest` k `digest` tvs `digest` cs And xs -> c `digest` @Word8 6 `digest` xs }}} and {{{#!hs -- tAG_BITS_MAX = (1 `shiftL` tAG_BITS) :: Int tAG_BITS_MAX = 1 `shiftL` @Int tAG_BITS }}} ---- I would still say the main usefulness is pedagogy: I will not introduce invalid syntax when explaining things to newcomers, but for questions like [https://www.reddit.com/r/haskellquestions/comments/5mtk8v/instance_eq_question/ this] {{{#!hs Nodo x ys zs == Nodo x' ys' zs' = x == x' && ys == ys' && zs == zs' }}} maybe it would help to write it like this, to show the different instantiations of `==` {{{#!hs Nodo x ys zs == Nodo x' ys' zs' = x == @a x' && ys == @(Heap a) ys' && zs == @(Heap a) zs' }}} In the end it's up to what the community thinks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 14:56:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 14:56:16 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.36b1e6d068eb2cdb9e65f89a2880e255@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): These instances feel extremely straightforward and uncontroversial to me. Mind whipping up a Phabricator Diff to add them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 15:18:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 15:18:01 -0000 Subject: [GHC] #10933: REMOVED pragma In-Reply-To: <047.034826e24c434b8ddb0afbdd6905b9d3@haskell.org> References: <047.034826e24c434b8ddb0afbdd6905b9d3@haskell.org> Message-ID: <062.dc2586ffd55a618815df33ed2340452f@haskell.org> #10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Should `REMOVED` pragmas mention the namespace of the removed thing? For example, if you had: {{{#!hs {-# REMOVED Foo #-} }}} Then without further information, `Foo` could be interpreted as both a data constructor and a type constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 15:32:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 15:32:53 -0000 Subject: [GHC] #13094: Poor register allocation and redundant moves when using `foreign import prim` In-Reply-To: <048.f20d5b598587307897dc5d81cca8cb87@haskell.org> References: <048.f20d5b598587307897dc5d81cca8cb87@haskell.org> Message-ID: <063.23333a9be8331cc01e6d0daea7def81d@haskell.org> #13094: Poor register allocation and redundant moves when using `foreign import prim` ---------------------------------+---------------------------------------- Reporter: jberryman | Owner: 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: #12232 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by jberryman: @@ -153,1 +153,1 @@ - are less easy to sort through, e.g. a random snippet: + are less easy to sort through. @@ -155,45 +155,1 @@ - {{{ - xorq %rdi,%r8 - movq %r14,%rdi - shrq $32,%rdi - shlq $32,%r14 - orq %rdi,%r14 - addq %r8,%r14 - movq %r14,%rdi - addq %rsi,%rdi - movq %rsi,%r10 - shrq $51,%r10 - shlq $13,%rsi - orq %r10,%rsi - xorq %rdi,%rsi - movq %r8,%r10 - shrq $43,%r10 - shlq $21,%r8 - orq %r10,%r8 - xorq %r14,%r8 - movq %rax,%r10 - shrq $32,%r10 - shlq $32,%rax - orq %r10,%rax - addq %r8,%rax - movq %rax,%r10 - }}} - - Intuitively this is also bad, after all the haskell we're compiling looks - almost trivially like the good assembly we'd like/expect (although perhaps - {{{rotl}}} is shaking things up here, as we have to implement it with two - shifts and an OR): - - {{{#!hs - -- in the Identity monad - do v0 <- return $ v0 + v1 - v1 <- return $ rotl v1 13 - v1 <- return $ v1 `xor` v0 - v0 <- return $ rotl v0 32 - v2 <- return $ v2 + v3 - v3 <- return $ rotl v3 16 - v3 <- return $ v3 `xor` v2 - v0 <- return $ v0 + v3 - v3 <- return $ rotl v3 21 - v3 <- return $ v3 `xor` v0 - }}} + '''EDIT''': extraneous information removed New description: This may well be the same as #12232 but I didn't want to risk hijacking that one. I've been looking at the dumped asm from a library where I use `foreign import prim` to call a simple assembly routine (that may be irrelevant). I see many `movq` instructions, and when I traced them by hand many or most seemed superfluous saving and restoring of registers. Here is a contiguous and mostly self-contained snippet of the assembly, with notes. I have four values I'm interested in V0, V1, V2, V3 which I started tracing at the note "registers good for sipRound_s_x2 at this point". Below I specifically follow V3 through the assmebly, marking lines with {{{"*** V3 ***"}}}, and the moves don't seem sensible to my (untrained) eye: {{{#!gas _c7Ns: movq %r9,%rbx movq %rax,%r9 movq %r8,%rax ; *** V3 *** movq %rbx,%r8 movq %rdi,%rbx movq %rax,%rdi ; *** V3 (back to rdi!) *** movq %rsi,%rax movq %rbx,%rsi movq %r14,%rbx movq %rax,%r14 movq %rcx,16(%rbp) addq $16,%rbp jmp *8(%rbp) .align 8 .quad 836 .quad 32 block_info: _c7Nk: movq 16(%rbp),%rax movq $8,16(%rbp) movq 24(%rbp),%rcx incq %rcx movq %rcx,24(%rbp) movq 32(%rbp),%rdx incq %rdx movq %rdx,32(%rbp) xorq 8(%rbp),%rbx addq $16,%rbp movl $8,%r8d xorl %r9d,%r9d _n7T1: movq %rax,64(%rsp) movq %r8,%rax ; --- registers good for sipRound_s_x2 at this point ------ movq %rdi,%r8 ; moving V3 *OUT* of rdi *** V3 *** movq %rsi,%rdi ; moving V2 *OUT* of rdi movq %r14,%rsi ; moving V1 *OUT* of r14 movq %rbx,%r14 ; moving V0 *OUT* of rbx movq 64(%rsp),%rbx _c7My: ; (NOTE: there are a few jumps to here from other sections not included here) cmpq 24(%rbx),%rdx je _c7Ns _c7Nr: movq 16(%rbx),%r10 movzbl (%r10,%rdx,1),%r10d cmpq $1,%rax jne _c7N9 _c7Nl: movq $block_info,-16(%rbp) shlq $8,%r9 orq %r10,%r9 ;----- at this point (name: register): V0: r14, V1: rsi, V2: rdi, V3: r8 movq %rdi,%rax ; save rdi, trying to be rsi movq %r8,%rdi ; prepared rdi(V3) *** V3 *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi ; prepared rsi(V2) movq %r14,%rax movq %rcx,%r14 ; prepared r14(V1) movq %rbx,%rcx movq %rax,%rbx ; prepared rbx(V0) movq %r9,-8(%rbp) movq %rcx,(%rbp) addq $-16,%rbp jmp sipRound_s_x2 .align 8 .quad 1733 .quad 32 block_info: _c7N2: movq 24(%rbp),%rax movq $7,24(%rbp) movq 32(%rbp),%rcx incq %rcx movq %rcx,32(%rbp) movq 40(%rbp),%rdx incq %rdx movq %rdx,40(%rbp) movq 16(%rbp),%r8 xorq 8(%rbp),%rbx addq $24,%rbp movl $7,%r9d _n7T2: movq %rax,64(%rsp) movq %r9,%rax movq %r8,%r9 movq %rdi,%r8 movq %rsi,%rdi movq %r14,%rsi movq %rbx,%r14 movq 64(%rsp),%rbx jmp _c7My _c7N9: cmpq $1,%rax jbe _c7N3 _c7MW: decq %rax movq %rax,(%rbp) incq %rcx movq %rcx,8(%rbp) incq %rdx movq %rdx,16(%rbp) shlq $8,%r9 orq %r10,%r9 jmp _c7My _c7N3: movq $block_info,-24(%rbp) movq %rdi,%rax movq %r8,%rdi ; *** V3 (back to rdi!) *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi movq %r14,%rax movq %rcx,%r14 movq %rbx,%rcx movq %rax,%rbx movq %r9,-16(%rbp) movq %r10,-8(%rbp) movq %rcx,(%rbp) addq $-24,%rbp jmp sipRound_s_x2 .size $whashRemainingBytes_info, .-$whashRemainingBytes_info }}} This is my first time looking closely at assembly, so maybe this is normal or no big deal performance-wise (I haven't gotten around to trying to correlate number of moves with performance of my variations yet), or I'm missing something obvious. I wasn't able to make sense of an objdump-ed version of the llvm-compiled program. The code for the version where the same {{{sipRound}}} stuff is implemented in normal haskell also has a lot of moves (even more in fact), but they seem interspersed throughout and are less easy to sort through. '''EDIT''': extraneous information removed You can check out the branch here, which I'll keep at 838b27a: https://github.com/jberryman/hashabler/tree/saved-branch-exhibiting- seemingly-bad-register-allocation You can build and observe the assembly with: {{{ $ cabal configure -fdev --enable-benchmarks && cabal build core $ gvim ./dist/build/core/core-tmp/core.dump-asm }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 15:35:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 15:35:32 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.eebf23a0405b0b0a779bf1ce65fd74f1@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Erik says not fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 16:18:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 16:18:46 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.0e8c88db4c36a06091a6f479c0beb549@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's the offending part of `containers` this time: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} module Containers (partition) where import GHC.Exts (isTrue#, reallyUnsafePtrEquality#) data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip type Size = Int data StrictPair a b = !a :*: !b infixr 1 :*: -- | Convert a strict pair to a standard pair. toPair :: StrictPair a b -> (a, b) toPair (x :*: y) = (x, y) {-# INLINE toPair #-} partition :: (a -> Bool) -> Set a -> (Set a,Set a) partition p0 t0 = toPair $ go p0 t0 where go _ Tip = (Tip :*: Tip) go p t@(Bin _ x l r) = case (go p l, go p r) of ((l1 :*: l2), (r1 :*: r2)) | p x -> (if l1 `ptrEq` l && r1 `ptrEq` r then t else link x l1 r1) :*: merge l2 r2 | otherwise -> merge l1 r1 :*: (if l2 `ptrEq` l && r2 `ptrEq` r then t else link x l2 r2) merge :: Set a -> Set a -> Set a merge = undefined link :: a -> Set a -> Set a -> Set a link = undefined ptrEq :: a -> a -> Bool ptrEq x y = isTrue# (reallyUnsafePtrEquality# x y) {-# INLINE ptrEq #-} }}} And here's the Core Lint error: {{{ $ ghc/inplace/bin/ghc-stage2 Containers2.hs -fforce-recomp -dcore-lint -O2 [1 of 1] Compiling Containers ( Containers2.hs, Containers2.o ) *** Core Lint errors : in result of Simplifier *** : warning: In the expression: tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) ww_s4m3 l_a2PV) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ (Set a) ww_s4m3 l_a2PV *** Offending Program *** merge :: forall a. Set a -> Set a -> Set a [LclId, Str=x, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=NEVER}] merge = \ (@ a_a3Sm) -> raise# @ SomeException @ 'PtrRepLifted @ (Set a -> Set a -> Set a) (noinline @ ([Char] -> CallStack -> SomeException) errorCallWithCallStackException undefined9 (PushCallStack undefined8 undefined1 (PushCallStack (unpackCString# "undefined"#) (SrcLoc (unpackCString# "main"#) (unpackCString# "Containers"#) (unpackCString# "Containers2.hs"#) (I# 36#) (I# 9#) (I# 36#) (I# 18#)) EmptyCallStack))) link :: forall a. a -> Set a -> Set a -> Set a [LclId, Str=x, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=NEVER}] link = \ (@ a_a3S7) -> raise# @ SomeException @ 'PtrRepLifted @ (a -> Set a -> Set a -> Set a) (noinline @ ([Char] -> CallStack -> SomeException) errorCallWithCallStackException undefined9 (PushCallStack undefined8 undefined1 (PushCallStack (unpackCString# "undefined"#) (SrcLoc (unpackCString# "main"#) (unpackCString# "Containers"#) (unpackCString# "Containers2.hs"#) (I# 39#) (I# 9#) (I# 39#) (I# 18#)) EmptyCallStack))) lvl_s4aT :: forall a. StrictPair (Set a) (Set a) [LclId, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] lvl_s4aT = \ (@ a_a3Sv) -> :*: @ (Set a) @ (Set a) (Tip @ a) (Tip @ a) Rec { poly_go_s4aS [InlPrag=INLINE[0]] :: forall a. (a -> Bool) -> Set a -> StrictPair (Set a) (Set a) [LclId, Arity=2, CallArity=2, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (@ a_s4lW) (w_s4lX [Occ=Once] :: a -> Bool) (w_s4lY [Occ=Once] :: Set a) -> case $wpoly_go_s4m1 @ a w_s4lX w_s4lY of { (# ww_s4m3 [Occ=Once], ww_s4m4 [Occ=Once] #) -> :*: @ (Set a) @ (Set a) ww_s4m3 ww_s4m4 }}] poly_go_s4aS = \ (@ a_s4lW) (w_s4lX :: a -> Bool) (w_s4lY :: Set a) -> case $wpoly_go_s4m1 @ a w_s4lX w_s4lY of { (# ww_s4m3, ww_s4m4 #) -> :*: @ (Set a) @ (Set a) ww_s4m3 ww_s4m4 } $wpoly_go_s4m1 [InlPrag=[0], Occ=LoopBreaker] :: forall a. (a -> Bool) -> Set a -> (# Set a, Set a #) [LclId, Arity=2, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [60 30] 194 30}] $wpoly_go_s4m1 = \ (@ a_s4lW) (w_s4lX :: a -> Bool) (w_s4lY :: Set a) -> case w_s4lY of wild_Xo { Bin dt_d44n [Dmd=] x_a2PU [Dmd=] l_a2PV [Dmd=] r_a2PW [Dmd=] -> case $wpoly_go_s4m1 @ a w_s4lX l_a2PV of { (# ww_s4m3, ww_s4m4 #) -> case $wpoly_go_s4m1 @ a w_s4lX r_a2PW of { (# ww_X4mP, ww_X4mR #) -> case w_s4lX x_a2PU of { False -> case merge of wild_00 { }; True -> case case tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) ww_s4m3 l_a2PV) of { False -> case link of wild_00 { }; True -> case tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) ww_X4mP r_a2PW) of { False -> case link of wild_00 { }; True -> wild_Xo } } of dt_X3KG [Dmd=] { __DEFAULT -> case merge of wild_00 { } } } } }; Tip -> (# Tip @ a, Tip @ a #) } end Rec } partition :: forall a. (a -> Bool) -> Set a -> (Set a, Set a) [LclIdX, Arity=2, Str=m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (@ a_a3Sv) (p0_a2PP [Occ=Once] :: a -> Bool) (t0_a2PQ [Occ=Once] :: Set a) -> case poly_go_s4aS @ a p0_a2PP t0_a2PQ of { :*: x_a2PN [Occ=Once] y_a2PO [Occ=Once] -> (x_a2PN, y_a2PO) }}] partition = \ (@ a_a3Sv) (p0_a2PP :: a -> Bool) (t0_a2PQ :: Set a) -> case $wpoly_go_s4m1 @ a p0_a2PP t0_a2PQ of { (# ww_s4m3, ww_s4m4 #) -> (ww_s4m3, ww_s4m4) } $trModule_s4a3 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] $trModule_s4a3 = TrNameS "main"# $trModule_s4a4 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 50 20}] $trModule_s4a4 = TrNameS "Containers"# $trModule :: Module [LclIdX, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module $trModule_s4a3 $trModule_s4a4 $tc'Tip_s4a5 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] $tc'Tip_s4a5 = TrNameS "'Tip"# $tc'Tip :: TyCon [LclIdX, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tc'Tip = TyCon 2793269457193232401## 14910929446856376197## $trModule $tc'Tip_s4a5 $tc'Bin_s4a6 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] $tc'Bin_s4a6 = TrNameS "'Bin"# $tc'Bin :: TyCon [LclIdX, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tc'Bin = TyCon 4548370254528349800## 3424913680517968384## $trModule $tc'Bin_s4a6 $tcSet_s4a7 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] $tcSet_s4a7 = TrNameS "Set"# $tcSet :: TyCon [LclIdX, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tcSet = TyCon 3037255313641890014## 1627524838438604808## $trModule $tcSet_s4a7 $tc':*:_s4a8 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] $tc':*:_s4a8 = TrNameS "':*:"# $tc':*: :: TyCon [LclIdX, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tc':*: = TyCon 9247104382896135333## 1281726570460431133## $trModule $tc':*:_s4a8 $tcStrictPair_s4a9 :: TrName [LclId, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 50 20}] $tcStrictPair_s4a9 = TrNameS "StrictPair"# $tcStrictPair :: TyCon [LclIdX, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tcStrictPair = TyCon 18371072474651713953## 8175359178144728928## $trModule $tcStrictPair_s4a9 *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 17:21:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 17:21:36 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.b4ca0b66ea97733fcb06f1c3ab9b7826@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I suspect it will be helpful to enhance let/app error reporting to make it explain why it believes the let/app invariant is being violated. I can start looking into doing so today, unless Simon disagrees. One vague possibility is that evaluatedness tracking breaks down when the pairs are unboxed, but I still don't see why evaluatedness should have anything to do with let/app in this context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 17:43:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 17:43:27 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows Message-ID: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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 32-bit Windows build usually segfaults when building Haddock. A bisection reveals, {{{ $ git bisect log git bisect start # good: [4986837f8168cacf95c24fecc84d7b36c47f3c11] rules/build-prog: Ensure programs depend upon their transitive deps git bisect good 4986837f8168cacf95c24fecc84d7b36c47f3c11 # bad: [fb0f4cf66f3fc7590821e6688440bf86c25aced1] Install toplevel handler inside fork. git bisect bad fb0f4cf66f3fc7590821e6688440bf86c25aced1 # good: [2086d86674324c0f5f21e23acbe26f4517843f57] Fix Windows build after Ticky changes git bisect good 2086d86674324c0f5f21e23acbe26f4517843f57 # good: [8f8f0b62ec106b0d503240c4cb7510a7cb4ddbb6] Fix Windows build after Ticky changes git bisect good 8f8f0b62ec106b0d503240c4cb7510a7cb4ddbb6 # good: [b688f0056a1694bb0db3ca2b84ab5505ba9947d7] Fix handling of package-db entries in .ghc.environment files, etc. git bisect good b688f0056a1694bb0db3ca2b84ab5505ba9947d7 # good: [b688f0056a1694bb0db3ca2b84ab5505ba9947d7] Fix handling of package-db entries in .ghc.environment files, etc. git bisect good b688f0056a1694bb0db3ca2b84ab5505ba9947d7 # good: [c904258319b8eb6e47ba727c667bca765537802b] runghc: use executeFile to run ghc process on POSIX git bisect good c904258319b8eb6e47ba727c667bca765537802b # good: [c904258319b8eb6e47ba727c667bca765537802b] runghc: use executeFile to run ghc process on POSIX git bisect good c904258319b8eb6e47ba727c667bca765537802b # good: [28c62bb588f7026d9985afe235cbeec5e3fd9a76] Fix Trac #12797: approximateWC git bisect good 28c62bb588f7026d9985afe235cbeec5e3fd9a76 # bad: [6bee8644d959ec77745d835c8c4453f2147bd8d7] rts: Fix build when linked with gold git bisect bad 6bee8644d959ec77745d835c8c4453f2147bd8d7 # good: [60c299a2278c351abed1ea51a1c2ee5459033fa9] Pass --no-pie to GCC git bisect good 60c299a2278c351abed1ea51a1c2ee5459033fa9 # bad: [cca8ceec97d6b8b031dec837825b97609dd7288f] Read parentheses better git bisect bad cca8ceec97d6b8b031dec837825b97609dd7288f # bad: [fefe02c0324a25a52455a61f7f6e48be6d82d1ab] Pass -no-pie to GCC git bisect bad fefe02c0324a25a52455a61f7f6e48be6d82d1ab # good: [3da461d9ddc8ff6fe14ee9572b617d8e3753de2e] Revert "Pass --no-pie to GCC" git bisect good 3da461d9ddc8ff6fe14ee9572b617d8e3753de2e # first bad commit: [fefe02c0324a25a52455a61f7f6e48be6d82d1ab] Pass -no- pie to GCC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 17:59:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 17:59:00 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.75b24c805aaf8e11b33bff1bfd13bda3@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Evaluatedness matters because the let/app invariant says that an argument of an application of unlifted type should be ok for speculation. And an application of a primop `foo# bar baz` is only considered ok for speculation if `bar` and `baz` are known to be evaluated, since otherwise evaluating `foo# bar baz` might evaluate `bar` and `baz` which could diverge. Actually `reallyUnsafePtrEquality#` never evaluates its arguments but the ok for speculation check does not know that; and if it did then the real underlying issue would still not be solved. I'm guessing that the expression `tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) ww_s4m3 l_a2PV)` was produced at an earlier stage when the first argument was known to be evaluated. Looks like it might have been before worker/wrapper, since `go` produces a `StrictPair` whose fields are known to be evaluated. But `(# , #)` can hold unevaluated things so w/w causes us to lose the information that `ww_s4m3` is evaluated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 18:33:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 18:33:05 -0000 Subject: [GHC] #13101: Enable GHC to be loaded into GHCi Message-ID: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> #13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- It would be very helpful for development to be able to load GHC itself into GHCi. In principle this shouldn't be so hard since GHC is just another Haskell program. However, in practice there are a number of modules which use unboxed tuples, which the interpreter does not support. However, it should be possible to the convince GHC to use object code for just these modules and interpret the rest. I have a few attempts at this here (https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e). See the following related mailing list threads, * https://mail.haskell.org/pipermail/ghc-devs/2017-January/013545.html * https://mail.haskell.org/pipermail/ghc-devs/2016-March/011555.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 18:57:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 18:57:13 -0000 Subject: [GHC] #13079: Fix typo in comment In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.b9df5233c15f5e74acd838f977be11ea@haskell.org> #13079: Fix typo in comment -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is fine; thanks for the patch, forki! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:16:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:16:04 -0000 Subject: [GHC] #13101: Enable GHC to be loaded into GHCi In-Reply-To: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> References: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> Message-ID: <061.a4fc6c44127923602db1c7aadf2862b6@haskell.org> #13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- 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): Just for reference, #1257 explains why we have no unboxed tuple support in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #12958: Properly detect if GHCi is running in MinTTY In-Reply-To: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> References: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> Message-ID: <065.78826198ec3237ac1738eca94df297f5@haskell.org> #12958: Properly detect if GHCi is running in MinTTY -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2878 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6fe9b057396b4ace73106dc9c3c7fcb72a216bfa/ghc" 6fe9b057/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6fe9b057396b4ace73106dc9c3c7fcb72a216bfa" Properly detect MinTTY when running GHCi on Windows Before, we detecting the presence of MinTTY on Windows in a very imprecise way: by checking if the `_` environment variable was set. Not only is this easy to circumvent, but it also yields false positives on terminals like ConEmu. This changes the test to use the `GetFileInformationByHandleEx` function instead, which provides a far more accurate check for MinTTY's presence. I've tested this on PowerShell, MSYS2, Cygwin, ConEmu, and Git Bash, and it does the right thing on each one. Fixes #12958. Test Plan: Run GHCi on many different Windows and MinTTY consoles Reviewers: erikd, Phyx, austin, bgamari Reviewed By: Phyx, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2878 GHC Trac Issues: #12958 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #11040: Split SRT tables on Mac OS In-Reply-To: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> References: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> Message-ID: <060.db192b9f798c6ddfdee10edb7426340b@haskell.org> #11040: Split SRT tables on Mac OS ---------------------------------+---------------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2911 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"0a6c257de5c217436ec61fdf4b06bca059181f83/ghc" 0a6c257d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a6c257de5c217436ec61fdf4b06bca059181f83" -dead_strip is now the default on Darwin This enables subsections-via-symbols (-dead_strip) by default on Darwin. The Static Reference Table (SRT) needs to be split in order for -dead_strip to be helpful, so this commit always splits it on Darwin systems. Test Plan: GHC CI on Darwin Reviewers: erikd, austin, bgamari Reviewed By: erikd, bgamari Subscribers: erikd, thomie Differential Revision: https://phabricator.haskell.org/D2911 GHC Trac Issues: #11040, #13049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #13049: Make `-dead_strip` the default on Darwin In-Reply-To: <047.db5905269068938cc53fd620b92bef9f@haskell.org> References: <047.db5905269068938cc53fd620b92bef9f@haskell.org> Message-ID: <062.c081182c7c89aa5e6a975369f7faada3@haskell.org> #13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | 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:D2911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0a6c257de5c217436ec61fdf4b06bca059181f83/ghc" 0a6c257d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a6c257de5c217436ec61fdf4b06bca059181f83" -dead_strip is now the default on Darwin This enables subsections-via-symbols (-dead_strip) by default on Darwin. The Static Reference Table (SRT) needs to be split in order for -dead_strip to be helpful, so this commit always splits it on Darwin systems. Test Plan: GHC CI on Darwin Reviewers: erikd, austin, bgamari Reviewed By: erikd, bgamari Subscribers: erikd, thomie Differential Revision: https://phabricator.haskell.org/D2911 GHC Trac Issues: #11040, #13049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #12707: Add contributed performance testcase In-Reply-To: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> References: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> Message-ID: <061.9fa9039746f5cb23ee8a56f61757f459@haskell.org> #12707: Add contributed performance testcase -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | 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:"e8d74321b5b24afcb4230510fd6e4c4ecf6f3e19/ghc" e8d74321/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e8d74321b5b24afcb4230510fd6e4c4ecf6f3e19" testsuite: Add performance testcase from #12707 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.fe27f59b83dddb647115da1149bd5784@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: patch Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2790 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"12ad4d417b89462ba8e19a3c7772a931b3a93f0e/ghc" 12ad4d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12ad4d417b89462ba8e19a3c7772a931b3a93f0e" Throw an exception on heap overflow This changes heap overflow to throw a HeapOverflow exception instead of killing the process. Test Plan: GHC CI Reviewers: simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2790 GHC Trac Issues: #1791 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #13049: Make `-dead_strip` the default on Darwin In-Reply-To: <047.db5905269068938cc53fd620b92bef9f@haskell.org> References: <047.db5905269068938cc53fd620b92bef9f@haskell.org> Message-ID: <062.45e3b7b63f4492563a45762e7801adb5@haskell.org> #13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | 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:D2911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"58e68b37e74fd226ef6be1d59785cb899e01dbd5/ghc" 58e68b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="58e68b37e74fd226ef6be1d59785cb899e01dbd5" Enable subsections via symbols on iOS Test Plan: GHC CI Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2915 GHC Trac Issues: #11040, #13049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #11592: Self-kinded type variable accepted In-Reply-To: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> References: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> Message-ID: <061.8e9cf46aa0a14da85c23e95580927cfd@haskell.org> #11592: Self-kinded type variable accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2914 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8a76d32e4fbdafe787a0f5b2a492c0d0ea1ed980/ghc" 8a76d32e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a76d32e4fbdafe787a0f5b2a492c0d0ea1ed980" Check that type variable does not reference itself in its kind signature This fixes #11592. Test Plan: validate Reviewers: simonpj, austin, bgamari, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2914 GHC Trac Issues: #11592 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.8428c0f431018d83ce66846e8447965b@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6de7613604216f65fae92d8066a078bf9cd3c088/ghc" 6de76136/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6de7613604216f65fae92d8066a078bf9cd3c088" event manager: Don't worry if attempt to wake dead manager fails This fixes #12038, where the TimerManager would attempt to wake up a manager that was already dead, resulting in setnumcapabilities001 occassionally failing during shutdown with unexpected output on stderr. I'm frankly still not entirely confident in this solution but perhaps it will help to get a few more eyes on this. My hypothesis is that the TimerManager is racing: thread TimerManager worker ------- -------------------- requests that thread manager shuts down begins to clean up, closing eventfd calls wakeManager, which tries to write to closed eventfd To prevent this `wakeManager` will need to synchronize with the TimerManger worker to ensure that the worker doesn't clean up the `Control` while another thread is trying to send a wakeup. However, this would add a bit of overhead on every timer interaction, which feels rather costly for what is really a problem only at shutdown. Moreover, it seems that the event manager (e.g. `GHC.Event.Manager`) is also afflicted by a similar race. This patch instead simply tries to catch the write failure after it has happened and silence it in the case that the fd has vanished. It feels rather hacky but it seems to work. Test Plan: Run `setnumcapabilities001` repeatedly Reviewers: austin, hvr, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2926 GHC Trac Issues: #12038 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #13095: Remove deprecated InteractiveEval API In-Reply-To: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> References: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> Message-ID: <060.8840de9b9312dd2c5aaf1e7b0ad93a60@haskell.org> #13095: Remove deprecated InteractiveEval API -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | 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:D2949 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eee819943a0ea05af369fe3c728b865094e8fe33/ghc" eee81994/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eee819943a0ea05af369fe3c728b865094e8fe33" Remove deprecated InteractiveEval API Remove `RunResult(..)`, `runStmt`, and `runStmtWithLocation`. These were all deprecated and documented as slated for removal in GHC 7.14, which I figure means 8.2. See cf7573b8207bbb17c58612f3345e0b17d74cfb58 for an explanation of why this change was made. Reviewers: simonpj, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2949 GHC Trac Issues: #13095 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #11040: Split SRT tables on Mac OS In-Reply-To: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> References: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> Message-ID: <060.ad3ca0eaf631a8d08df03e8f5dec2835@haskell.org> #11040: Split SRT tables on Mac OS ---------------------------------+---------------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2911 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"58e68b37e74fd226ef6be1d59785cb899e01dbd5/ghc" 58e68b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="58e68b37e74fd226ef6be1d59785cb899e01dbd5" Enable subsections via symbols on iOS Test Plan: GHC CI Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2915 GHC Trac Issues: #11040, #13049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:21:41 -0000 Subject: [GHC] #13096: Remove tyConString In-Reply-To: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> References: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> Message-ID: <060.badd795cd1cd3e88070864b1419c9f9d@haskell.org> #13096: Remove tyConString -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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:D2950 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5857dfb8873eac6e682802524e2c2d9b96bb42f4/ghc" 5857dfb8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5857dfb8873eac6e682802524e2c2d9b96bb42f4" Remove tyConString `tyConString` has been deprecated since GHC 7.4. It's time for it to go. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2950 GHC Trac Issues: #13096 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:23:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:23:24 -0000 Subject: [GHC] #12958: Properly detect if GHCi is running in MinTTY In-Reply-To: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> References: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> Message-ID: <065.68d936dea2ae3b43f1beb11e582e4763@haskell.org> #12958: Properly detect if GHCi is running in MinTTY -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2878 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:24:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:24:21 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.1db7b56461df3dce6aa90cb7f87caa64@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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 Phyx-): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:23:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:23:53 -0000 Subject: [GHC] #11040: Split SRT tables on Mac OS In-Reply-To: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> References: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> Message-ID: <060.9921024507baec089edd032b49123534@haskell.org> #11040: Split SRT tables on Mac OS ---------------------------------+---------------------------------------- Reporter: olsner | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 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:D2911 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 Tue Jan 10 19:24:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:24:48 -0000 Subject: [GHC] #12707: Add contributed performance testcase In-Reply-To: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> References: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> Message-ID: <061.141e49357c36b7f3908eb953cfb31ba4@haskell.org> #12707: Add contributed performance testcase -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: normal | 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 Tue Jan 10 19:25:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:25:25 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.0920261b2d2be2e514c9fe484ed09d4d@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 6.8 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2790 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 Tue Jan 10 19:25:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:25:50 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.ad4c58fab2d5995a880000ae482f8bc7@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:25:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:25:54 -0000 Subject: [GHC] #11592: Self-kinded type variable accepted In-Reply-To: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> References: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> Message-ID: <061.00eec6112ba8beaa0d5b427c7dbf16e4@haskell.org> #11592: Self-kinded type variable accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks John! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:26:12 -0000 Subject: [GHC] #13049: Make `-dead_strip` the default on Darwin In-Reply-To: <047.db5905269068938cc53fd620b92bef9f@haskell.org> References: <047.db5905269068938cc53fd620b92bef9f@haskell.org> Message-ID: <062.4fb2aecdcfcad406ea4dcf48648d579a@haskell.org> #13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | 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): Phab:D2911 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 Tue Jan 10 19:27:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:27:06 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.7a90181610ee134f4742f61bb45d654e@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.2.1 Comment: I think comment:13 should fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:27:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:27:25 -0000 Subject: [GHC] #13095: Remove deprecated InteractiveEval API In-Reply-To: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> References: <045.241b444c1ae00b0493081ba506c128f9@haskell.org> Message-ID: <060.e7821b5b221e70cf046c5307a3bd9152@haskell.org> #13095: Remove deprecated InteractiveEval API -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | 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:D2949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:27:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:27:36 -0000 Subject: [GHC] #13096: Remove tyConString In-Reply-To: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> References: <045.9933f182d5360ccda100f364b73c8a68@haskell.org> Message-ID: <060.293d3ab1789015d6fd90dd129cda7214@haskell.org> #13096: Remove tyConString -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | 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:D2950 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:31:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:31:08 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.b26def26ec5ec12d73dd3057461b8970@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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): Indeed it seems that fefe02c0324a25a52455a61f7f6e48be6d82d1ab is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:40:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:40:24 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.24b44d5fe0f5a039f5fd927ffab04fb3@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | 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: #12795 | Differential Rev(s): Phab:D2876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:41:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:41:49 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.1027eed419f34da1f76a1c86c127e437@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | 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: #12795 | Differential Rev(s): Phab:D2876, Wiki Page: | Phab:D2952 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D2876 => Phab:D2876, Phab:D2952 Comment: Since I was morbidly curious, I decided to see how much effort it would take to tweak the autoconf scripts to support detecting pointer types. To my surprise, it wasn't bad at all! I've opened to Phab:D2952 to add `CTimer` back to `System.Posix.Types`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:45:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:45:13 -0000 Subject: [GHC] #12417: API annotations for unboxed sums needs reworking In-Reply-To: <043.00b31e92686f5920efa6f831cd588891@haskell.org> References: <043.00b31e92686f5920efa6f831cd588891@haskell.org> Message-ID: <058.a5b3763e238db1c0a960f3add095f088@haskell.org> #12417: API annotations for unboxed sums needs reworking -------------------------------------+------------------------------------- Reporter: osa1 | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): An unboxed tuple such as {{{#!hs (# | b | | | | | #) }}} Ends up in the parser via `tup_exprs` as {{{#!hs Sum 2 7 lexp }}} where `lexp` is a `LHsExpr` From an annotation perspective, the 5 `AnnVbar`s after the `b` are attached to `lexp`, but currently the leading `AnnVbar`s do not have a home. They need to be attached to the parent tuple expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:46:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:46:14 -0000 Subject: [GHC] #13101: Enable GHC to be loaded into GHCi In-Reply-To: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> References: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> Message-ID: <061.250b0c239f3d82735ae41d7633dd8f6a@haskell.org> #13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- 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 bgamari): Also, ticket:10965#comment:5 explains why you can't use `{-# OPTIONS_GHC -fobject-code #-}` to set `-fobject-code` on a per-module basis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:52:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:52:18 -0000 Subject: [GHC] #13101: Enable GHC to be loaded into GHCi In-Reply-To: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> References: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> Message-ID: <061.ae916d4f9d59a4aaf4f06ad0cb0ae17c@haskell.org> #13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- 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): More JFTR: Loading all of GHC into GHCi works if one simply `-fobject- code` for everything. This may be good enough for some uses cases (e.g. experimentation with exported functions, quick recompilation cycles using `ghcid`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 19:55:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 19:55:46 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.4cfbd410c7066a5a42317f2656246a95@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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): Phyx noted that the patch inadvertently removes a linker flag on Windows, {{{#!patch diff --git a/compiler/main/SysTools.hs b/compiler/main/SysTools.hs index 236bcfd..1ab5b13 100644 (file) --- a/compiler/main/SysTools.hs +++ b/compiler/main/SysTools.hs @@ -858,7 +860,7 @@ getLinkerInfo' dflags = do -- Note [Windows stack usage] -- Force static linking of libGCC -- Note [Windows static libGCC] - , "-Xlinker", "--stack=0x800000,0x800000", "-static- libgcc" ] + , "-static-libgcc" ] _ -> do -- In practice, we use the compiler as the linker here. Pass -- -Wl,--version to get linker version info. }}} I'm going to try reverting this bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:01:17 -0000 Subject: [GHC] #13090: Expose all unfoldings of overloaded functions by default In-Reply-To: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> References: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> Message-ID: <064.8f447582fbf37ef96f84cabd5436960f@haskell.org> #13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): As a user, yes, I would welcome an easy way to have "overloaded functions specialised at call sites". Attaching a pragma to each of them is not "easy", but a compiler option (per module, or per cabal project) is. If compile times/code sizes go up, so be it. It's a price to pay for faster executables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:16:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:16:23 -0000 Subject: [GHC] #13090: Expose all unfoldings of overloaded functions by default In-Reply-To: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> References: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> Message-ID: <064.d63cf7fd501ca6490162d82ce1028b5b@haskell.org> #13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:2 j.waldmann]: > As a user, yes, I would welcome an easy way to have "overloaded functions specialised at call sites". But there must be limits surely. For example in GHC there are plenty of functions that are hundreds of lines long. They happen to (mostly?) not be overloaded, but if they were then it would surely not be sensible to copy them into every client module once for every type at which they are used. > Attaching a pragma to each of them is not "easy", but a compiler option (per module, or per cabal project) is. Sure, but a compiler option is not "by default". > If compile times/code sizes go up, so be it. It's a price to pay for faster executables. If you opt into it, okay. Slow compile times are pretty much the most common complaint about GHC as far as I've seen. mpickering suggested on IRC that we might by default only do this for small functions; I'd be much happier about that (and it does seem like it would have real runtime performance gains). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:27:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:27:57 -0000 Subject: [GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger In-Reply-To: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> References: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> Message-ID: <065.c0ac31ff386260af0dc211f101d368cf@haskell.org> #13076: GHC panics can cause text-formatting changes from colorized error messages to linger -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809, #12785 | Differential Rev(s): Phab:D2932 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"22845adcc51b40040b9d526c36d2d36edbb11dd7/ghc" 22845ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22845adcc51b40040b9d526c36d2d36edbb11dd7" Fix terminal corruption bug and clean up SDoc interface. - Fix #13076 by wrapping `printDoc_` so that the terminal color is reset even if an exception occurs. - Add `printSDoc`, `printSDocLn`, and `bufLeftRenderSDoc` to keep `SDoc` values abstract (they are wrappers of `printDoc_`, `printDoc`, and `bufLeftRender` respectively). - Remove unused function: `printForAsm` Test Plan: manual Reviewers: RyanGlScott, austin, dfeuer, bgamari Reviewed By: dfeuer, bgamari Subscribers: dfeuer, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2932 GHC Trac Issues: #13076 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:27:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:27:57 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.e6d5801b6aa2814f8c07ad1baf7eb166@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: akio Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"09bce7accd330e99b1667f8b4eda7def722d6f0c/ghc" 09bce7ac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="09bce7accd330e99b1667f8b4eda7def722d6f0c" Mark *FB functions INLINE[0] (Fixes #13001) When fusion rules successfully fire, we are left with calls to *FB functions. They are higher-order functions, and therefore they often benefit from inlining. This is particularly important when then final consumer is a strict fold (foldl', length, etc.), because not inlining these functions means allocating a function closure for each element in the list, which often is more costly than what fusion eliminates. Nofib shows a slight increase in the binary size: ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------------ gen_regexps -0.3% 0.0% 0.000 0.000 0.0% puzzle +0.8% 0.0% 0.089 0.090 0.0% reptile +0.8% -0.0% 0.008 0.008 0.0% ------------------------------------------------------------------------ Min -0.3% -0.0% -7.3% -7.1% 0.0% Max +0.8% +0.0% +7.8% +7.7% +1.8% Geometric Mean +0.0% -0.0% +0.2% +0.2% +0.0% ------------------------------------------------------------------------ Reviewers: simonpj, austin, hvr, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2951 GHC Trac Issues: #13001 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:28:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:28:36 -0000 Subject: [GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger In-Reply-To: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> References: <050.183ede7853f3c7f87c7a0de7f9996734@haskell.org> Message-ID: <065.ecf43571d6df34951da94b651d37daa0@haskell.org> #13076: GHC panics can cause text-formatting changes from colorized error messages to linger -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809, #12785 | Differential Rev(s): Phab:D2932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:30:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:30:01 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.713106bfe0ad97f9d3245204ce04a4fb@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: akio Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:31:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:31:31 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.fe932517bedb8fe3be68fa69d9277cd8@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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): Indeed reverting the hund mentioned in comment:3 seems to have fixed things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 20:54:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 20:54:27 -0000 Subject: [GHC] #13090: Expose all unfoldings of overloaded functions by default In-Reply-To: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> References: <049.d93c1e36ec5e79570beafd072398af22@haskell.org> Message-ID: <064.89c9a5c9778f5f558b6a6ad258962c36@haskell.org> #13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Yes, I meant "opt-in" (for paying the price). Sorry, I did not understand that this ticket is about doing this per default. I should have read the discussion in the Phab ticket first. I guess you could count my remark as a vote for "-O3" suggested in https://phabricator.haskell.org/D2929#85930 Feel free to disregard (if you want this ticket here to be free of discussion). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 21:02:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 21:02:27 -0000 Subject: [GHC] #13080: Memory leak caused by nested monadic loops (was: Constant values are not floated out of the loop) In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.0d8b4f564f485ea7d391db4bfc9ebb19@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: | -------------------------------------+------------------------------------- Comment (by Feuerbach): I think I now understand what's going on here. (Basically, what Reid said.) I summarized my thoughts in this blog post: https://ro- che.info/articles/2017-01-10-nested-loop-space-leak I don't know what ghc can do here, but hopefully there is something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 21:10:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 21:10:03 -0000 Subject: [GHC] #13079: Fix typo in comment In-Reply-To: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> References: <044.0f1cbd04408c79d01ead779d6bd5ebe2@haskell.org> Message-ID: <059.dca303440ecd7ed7c47663df0d1f8431@haskell.org> #13079: Fix typo in comment -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:09:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:09:35 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.6f140417a9e28192035b1ce0c47f3392@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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, this `-Xlinker` change was originally introduced by 7b211b4e5a38efca437d76ea442495370da7cc9a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:09:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:09:56 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.6c374cb9a7c220454a5e7bae89616872@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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): D2891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"2be364ac8cf2f5cd3b50503e8b26f51eb46101e5/ghc" 2be364ac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2be364ac8cf2f5cd3b50503e8b26f51eb46101e5" Inline partially-applied wrappers Suppose we have ``` data Node a = Node2 !Int a a | Node3 !Int a a a instance Traversable Node where traverse f (Node2 s x y) = Node2 s <$> f x <*> f y ... ``` Since `Node2` is partially applied, we wouldn't inline its wrapper. The result was that we'd box up the `Int#` to put the box in the closure passed to `fmap`. We now allow the wrapper to inline when partially applied, so GHC stores the `Int#` directly in the closure. Reviewers: rwbarton, mpickering, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2891 GHC Trac Issues: #12990 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:18:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:18:42 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.713e813ec382fda5d80005fae6ba1378@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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 Phyx-): I think you mean f0af58df4b5d5ace750e7d7a91ad471284c1b429 The commit you quoted merely touched the same line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:24:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:24:28 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.00136c6c7fcf744ccebfd5aa7bebea07@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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 had meant that the commit I cited was the cause of the conflict. f0af58df4b5d5ace750e7d7a91ad471284c1b429 is indeed the original patch introducing the `-Xlinker` flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:25:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:25:40 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.a599896a7eecf9207163539d98dbac31@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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 Phyx-): Ah, sorry, misread :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:26:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:26:33 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode Message-ID: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- In --make mode there is a single EPS whose `eps_fam_inst_env` holds all type family instances that have been read from interface files from external packages for any reason. The type checker uses this field pervasively via `tcGetFamInstEnvs`. When compiling multiple files it's fairly easy to set up a situation in which 1. the first module to be compiled `A` loads an interface file `O.hi` from another package containing an orphan family instance (say, because it imports the module directly); 2. a later module `B` uses this instance to reduce a type, even though `B` has no dependency at all on the module `O` defining the instance. (The only tricky bit in arranging this is that since `B` cannot depend on `A`, a little good fortune is needed for GHC to decide to compile `B` after `A`.) Now another module could import `B` and obtain a function whose definition relies on a type family instance that is not visible from `B` at all, compromising type safety. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:27:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:27:48 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.cb7fac2f12d5211c8b7d05e25992702e@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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): D2891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:34:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:34:00 -0000 Subject: [GHC] #13093: Runtime linker chokes on LLVM function on Windows In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.51a7bb26a870528e8d33865c0cc184ef@haskell.org> #13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Hmm, Interesting, thanks for the report. I think the error message is also a bit of a regression. It seems we currently abort inside the `rts` while we used to return and let the Haskell code resolve it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 22:38:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 22:38:27 -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.f0f06a58e95c306f54538622c8c8c6b6@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: Are you sure? It used to be the case that instances simply accumulated, so a module could "see" an instance (of a type class, say) that it didn't import, even transitively. But I belived we fixed that some time ago. I think it's in the call to `hptInstances` in `tcRnImports`. Ah but that's the ''home'' package, and your point is about some external package. Maybe you are right... Can you show how this can compromise type safety. Presumably it's through an un-detected type-family inconsistency? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 23:20:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 23:20: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.6a71967c8a08cfab1cf95392a25409c7@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | 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): I think rwbarton is probably right; looking at the commit that fixed this for instances 4c834fdddf4d44d12039da4d6a2c63a660975b95 it doesn't look like I actually added any code for *family instances*. So we need to apply an analogous fix there. (I'm not sure what hptInstances is doing but I think it is something else?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 23:45:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 23:45:01 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.6ab89d3a366c36f07d89dd59e53320ab@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you! Sigh. Several things. '''First (1)'''. Consider {{{ data T a = MkT !a a f :: Int -> T Int f x = MkT (x+1) x }}} We'll generate a wrapper for `MkT`, called `$WMkT`, that does the evaluation. So the Core looks like this: {{{ $WMkT :: a -> T a $WMkT = /\a. \x:a y:a. case x of z { DEFAULT -> MkT y z } f = \x. $WMkT (x+1) x }}} After inlining the wrapper we get {{{ f x = case x+1 of y -> MkT y x }}} Here in Core the `MkT` is the "worker" constructor. It does ''not'' perform evaluation (that is done by the wrapper); it is purely passive. But when we pattern match against a `MkT` we know that the payload is already evaluated. So if we started with {{{ g (MkT x y) = MkT x (y+1) }}} we would initially get {{{ g = \v. case v of MkT x y -> case x of r { DEFAULT -> MkT r (y+1) }}} But since `x` is surely evaluated (since it is gotten from `MkT`) we can drop the `case x` to get {{{ g = \v. case v of MkT x y -> MkT r (y+1) }}} So far so good. But if GHC went wrong, we could construct the expression {{{ MkT (x+1) y }}} in which the first argument is not evaluated. That is not supposed to happen! And arguably Lint should, thereore, check that the argument of a strict data constructor (the constructor not the wrapper!) is definitely evaluated. But Lint doesn't check that check. Yet. '''Second (2)'''. The same applies to the argument to `dataToTag#`. The argument should be evaluated, and Lint should really check that it is. I don't know if there are any other primops with this property. I think probably not. '''Third (3)'''. Should the arguments to `reallyUnsafePtrEq'` be evaluated? Probably not. Maybe it's ok to compare unevaluated thunks. But then in fact `reallyUnsafePtrEq#` ''is'' ok-for-speculation evan if its args are not evaluated. But `exprOkForSpeculation` doesn't understand that. '''Fourth (4)'''. The Lint error in comment:17 is to do with propagation of evaluated-ness. Consider this Core {{{ f = \x. case x of y { DEFAULT -> MkT y y } }}} This is fine. But now CPR analyis spots that f has the CPR property and does a worker/wrapper split (it would need to have a bigger body for this to actually happen, but you get the idea): {{{ $wf = \x -> case x of y { DEFAULT -> (# y, y #) } f = \x. case $wf x of (# a, b #) -> MkT a b -- Wrapper }}} Now this is NOT fine. Look at that application of `MkT` in the wrapper for `f`: we know that `a` will be evaluated (because it's a result of `$wf`) but that is not immediately apparent. We need to mark `a` as evaluated somehow. We have a way to do that: just grep for {{{`setIdUnfolding` evaldUnfolding}}} in the compiler. But we aren't doing that right now. Now, Lint doesn't complain about f's wrapper because of (1) above (although I argue that it should). But it ''does'' complain in this example program, when `exprOkForSpeculation` fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 23:49:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 23:49:48 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.4f0de6a49a1900911bbf13f64f8f5167@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Conclusions * ToDo: augument Lint to check that args to strict data cons are evaluated. Ditto `dataToTag#`. * ToDo: (maybe) make `exprOkForSpeculation` more lenient for lazy primpops. * ToDo: make worker/wrapper produce eval'd flags on the wrapper for CPR. Will silence the Lint error in comment:17 There is no actual bug here, if you have Lint off. The problem is that Lint is reporting a non-error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 23:51:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 23:51:14 -0000 Subject: [GHC] #13103: The RTS loader/linker relies too heavily on file extensions. Message-ID: <044.7f944652f526a39908a6cf013b87c664@haskell.org> #13103: The RTS loader/linker relies too heavily on file extensions. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13093 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS linker & loader relies way too heavily on file extensions instead of the structure of the file. This means that if we have stuff like object files in archives that don't end with `.o` and `.p_o` we won't load them. Or import libraries etc. This should be changed to use the structure of the file header to determine what the file is. This means that GCC and binutils handle a lot more files than we currently do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 10 23:51:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jan 2017 23:51:39 -0000 Subject: [GHC] #13093: Runtime linker chokes on LLVM function on Windows In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.00409e7f1767c730bb1cfbaa48f2bc23@haskell.org> #13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #13103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:07:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:07: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.2301ca419696842d09a42038b26050f0@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha! You are right! The relevant ticket is #2182. One thing unsaid there is that non-orphan instances cannot be a problem because the module defining a non-orphan instance must be in the transitive closure of modules below the one being compiled. It's just orphan modules that we need to take care about. A huge shortcoming is that this very cunning plan has no Note describing the Grand Plan, at least not that I can see. There ought to be one, with references to the note from the scattered bits of code that implement it. It does seem plausible that that the same thing would work for family instances. Hooray. Finally `hptInstances` appears to do the job (including family instances) for the home package, by glomming up all the instances from the home- package modules below this one. But the clever orphan module approach should work for the home package too, so perhaps we can kill off `hptInstances`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:07:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:07:46 -0000 Subject: [GHC] #13104: runRW# ruins join points Message-ID: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: 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: -------------------------------------+------------------------------------- Found this while poking around in the example for #12781. Suppose we have code like this: {{{ let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n = ... loop (n+1) {- tail call -} ... in runRW# @ 'PtrRepLifted @ Int (loop 0) }}} We would love for `loop` to be a join point, but it can't be because it's invoked in the argument to `runRW#`. In this situation, we're often rescued by Float In, which we might hope to give us this: {{{ runRW# @ 'PtrRepLifted @ Int ( let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 ) }}} Two problems: 1. Float In won't do this to begin with because `loop 0` is a partial application. 2. It's still not eligible to be a join point, again because `loop 0` is a partial application. What we would //like// to see is this: {{{ runRW# @ 'PtrRepLifted @ Int ( \s0 -> let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 s0 ) }}} Now we're golden. But someone has to have thought to eta-expand the argument to `runRW#` first. (Float In should then float `loop` into the lambda because, due to the state hack, the lambda is considered one-shot.) Perhaps the simplifier should //always// eta-expand the argument to `runRW#`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:09:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:09:36 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.910127a50574f12154c9be73f829a5b9@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): #5775 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): Confirmed—with join points, `INLINE` vs. `NOINLINE` makes no difference. And indeed the key is that we move the case into `$w$j`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:12:42 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.2f7eef24d48d2283286dac883620c851@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: It seems unlikely that this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:23:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:23:17 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.d19c0020eebb92f7ff72af24241becba@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by nomeata): Where does this occurence of `runRW#` come from? Before adding hacks to the simplifier, it might be sufficient to eta- expand the argument there. For example, instead of {{{ runST (ST st_rep) = case runRW# st_rep of (# _, a #) -> a }}} write {{{ runST (ST st_rep) = case runRW# (\s. st_rep s) of (# _, a #) -> a }}} or, for good measure, {{{ runST (ST st_rep) = case runRW# (oneShot (\s. st_rep s)) of (# _, a #) -> a }}} Have you tried that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:42:34 -0000 Subject: [GHC] #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.bc2740559d35655719d5ba5bbce5fd05@haskell.org> #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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 lukemaurer): Confirmed—with join points, heap allocation drops from 23M to 70K. Looks like the simplifier is doing exactly what we want, and //all// the loops wind up as join points. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 00:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 00:42:58 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.5e2cffe17eeb508fd60e5b7b2a6339ae@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 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 bgamari): * version: 8.0.1 => 8.0.2 * milestone: 8.0.2 => 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 01:42:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 01:42:22 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps Message-ID: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Conal Elliott provided me with this puzzle: {{{ type family RepRep a ∷ RuntimeRep class HasRep a where type Rep a ∷ TYPE (RepRep a) repr ∷ a → Rep a abst ∷ Rep a → a type instance RepRep Int = IntRep instance HasRep Int where type Rep Int = Int# abst n = I# n repr (I# n) = n }}} I think we should accept. However, doing so (even with my solution to #12809 complete) is hard, because we frequently consult a kind in order to determine a runtime representation. When that kind is `TYPE (RepRep Int)`, the code generator throws up its arms in despair. The solution here is either to teach the code generator how to normalise types (requiring propagating the `FamInstEnvs`) or to do a whole-program transformation at some point (zonker? desugarer? maybe we can wait until !CorePrep or even unarisation?) to change ids whose types have kinds like `TYPE (RepRep Int)` into ids with types with kinds like `TYPE IntRep`. But I don't want to let this hold me up at the moment, so I'm posting here as a reminder to revisit this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 01:46:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 01:46:54 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.0b09d403cb819b84607a0d2d4d0536df@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | 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: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T13105 Comment: I've added a test case (in my work on #12809, at Phab:D2842), but it's a `compile_fail` test, just because code like this originally made my branch panic. It doesn't panic now, and I want to keep it that way until this bug is addressed properly. Fixing this bug should make the test succeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 01:57:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 01:57:38 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.b8cd8280ee7cc0e8251524abf6f8a5c4@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 02:16:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 02:16:30 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.13fcfc4159f5abf261c6d8b5751ca77c@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:15 rwbarton]: > I don't know if it's the sheer number of updates to this ticket, but this syntax is starting to look fairly natural to me. Yes, to my chagrin, I agree here. I retract my -1 from comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 02:17:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 02:17:03 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.ec7e06641ddc289229e84598109a8814@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Phab:D2931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record, I'm fully agreed with comment:11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 02:21:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 02:21:46 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.3fcb674a8cd9c8831f9d08399d300db0@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 goldfire): Replying to [comment:5 simonpj]: > Actually there is ''some'' justification for the status quo. ... except that, regardless of Reid's excellent example in comment:6, having `F Int = Bool` and `F Int = Char` in scope means that we can write a proof of `Bool ~ Char` in Core. Continuing the status quo means that Core Lint is much less useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 02:57:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 02:57:23 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.a2c95e984f350d37caa1d5ab4a9371aa@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Is there a reason ''not'' to make `exprOkForSpeculation` more lenient for `reallyUnsafePtrEquality#`? Having it otherwise seems inconsistent, but it's also possible that it doesn't enable useful floating or that it's too much trouble to make it happen. I dug around just a bit, and the only other lazy primitives I could find that might be safe for speculation were `unpackClosure#` and (under certain circumstances, maybe) `seq`. I'm somewhat concerned about the fact that the problem tracking evaluatedness was only revealed "by chance", because `exprOkForSpeculation` is (seemingly) too conservative about `reallyUnsafePtrEquality#`. Is there some way to make this tracking more robust? I understand that you and Max Bolingbroke worked on some possibly- related ideas in "Types are Calling Conventions". What's your intuition about whether the type system can help here without making life horrible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 05:24:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 05:24:12 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.33fef380f0e381b6d08d0437cbda4c44@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I believe the instance selection is all done in the type checker. Hopefully someone can tell you how to get that info! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 06:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 06:37:41 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints Message-ID: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: initTc | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Below is the error: I got the following error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161213 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] cp_a6SB :: t_a6SA[tau:1] (CHoleCan: cp) [W] minimal_a6SI :: t_a6SH[tau:1] (CHoleCan: minimal) [W] frames_a6SL :: t_a6SK[tau:1] (CHoleCan: frames) [W] ps_a6Tb :: t_a6Ta[tau:1] (CHoleCan: ps) [W] minimal_a6Ti :: t_a6Th[tau:1] (CHoleCan: minimal) [W] frames_a6Tm :: t_a6Tl[tau:1] (CHoleCan: frames) [W] map_hd_a6Tv :: t_a6Tu[tau:1] (CHoleCan: map_hd) [W] ps_a6Ty :: t_a6Tx[tau:1] (CHoleCan: ps)} It was created with this repo: https://github.com/codygman/minimal-frames- lookup-map/blob/master/src/Main.hs Apologies for the setup needed, but I also had to download judy-0.3.0 manually and then include it for it to build (not sure why, but unrelated problem I think). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 06:38:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 06:38:56 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints In-Reply-To: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> References: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> Message-ID: <062.11c42621885ac2af8252e52174a65d3e@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: initTc 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 codygman: @@ -5,0 +5,2 @@ + + {{{ @@ -17,0 +19,2 @@ + }}} + @@ -24,0 +28,3 @@ + + GHC Head is still compiling for me, but maybe I'll be able to try to + reproduce this with HEAD tomorrow. New description: Below is the error: I got the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161213 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] cp_a6SB :: t_a6SA[tau:1] (CHoleCan: cp) [W] minimal_a6SI :: t_a6SH[tau:1] (CHoleCan: minimal) [W] frames_a6SL :: t_a6SK[tau:1] (CHoleCan: frames) [W] ps_a6Tb :: t_a6Ta[tau:1] (CHoleCan: ps) [W] minimal_a6Ti :: t_a6Th[tau:1] (CHoleCan: minimal) [W] frames_a6Tm :: t_a6Tl[tau:1] (CHoleCan: frames) [W] map_hd_a6Tv :: t_a6Tu[tau:1] (CHoleCan: map_hd) [W] ps_a6Ty :: t_a6Tx[tau:1] (CHoleCan: ps)} }}} It was created with this repo: https://github.com/codygman/minimal-frames- lookup-map/blob/master/src/Main.hs Apologies for the setup needed, but I also had to download judy-0.3.0 manually and then include it for it to build (not sure why, but unrelated problem I think). GHC Head is still compiling for me, but maybe I'll be able to try to reproduce this with HEAD tomorrow. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:31:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:31:53 -0000 Subject: [GHC] #13107: Negative literal equal to minBound gives a spurious warning Message-ID: <044.def8d2f70cdee29238a18619ccf0af74@haskell.org> #13107: Negative literal equal to minBound gives a spurious warning -------------------------------------+------------------------------------- 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: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHCi: {{{ λ > import GHC.Int λ > -128 :: Int8 :25:2: warning: [-Woverflowed-literals] Literal 128 is out of the Int8 range -128..127 If you are trying to write a large negative literal, use NegativeLiterals -128 λ > minBound :: Int8 -128 }}} Since `-128 :: Int8` is equal to `minBound :: Int8` this warning is not correct. Similar issues exist for `Int16`, `Int32` etc. Suspect this is related to the fix for #8542. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:38:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:38:34 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.506ba28fc6f2075fdc1b7e550f37008c@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by simonpj): What does the code for `loop` look like? Why isn't it eta-expaned anyway? What's the source code for the example to reproduce this? In #12781 you said that join points solved the example there... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:48:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:48:47 -0000 Subject: [GHC] #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.876ba99b0a95baaea93b6348daf9f58d@haskell.org> #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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): > As I have stated, I believe there are many use cases, even to the common worker/wrapper pattern that seeks to reduce the amount of parameter passing by enclosing a recursive worker closure inside a wrapper; any gains from this pattern could be cancelled and more if the wrapped enclosure is less efficient. Let me say what I ''think'' you are saying. Consider {{{ f x p q = let g y = ...g y'...x... in (g p, g q) }}} Left as-is we allocate a closure for `g` every time we call `f`. But instead we could lambda-lift `g`: {{{ g2 x y = ...g2 x y'...x... f x p q = (g2 x p, g2 x q) }}} Now we don't allocate a closure for `g`. That is good. Is this what you mean? We don't want to do this in general, early in optimisation, because we get huge benefits from being able to "see" the binding site of `g`'s free variable `x`. But these benefits are over when it comes to code generation. So we have experimented with so-called "late lambda lifting" (LLF). There's a whole wiki page about it: [wiki:LateLamLift]. It can be a real win. One obstacle to LLF is, ironically, that it can destroy join points (see the wiki page). A second benefit of Luke's new join-point work is that it becomes much easier to ensure that LLF doesn't destroy join points, and thus renders it much more practical. I think Luke will turn his attention to it once join points are solidly in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:49:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:49:49 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows Message-ID: <044.d631d36f93220766b68ac911126e9f93@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: System | Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently all that we have is "Segmentation fault/access violation in generated code" message. My patch adds type (read/write/dep violation) and location information to the diagnostics. This may help tremendously when analyzing the problems. Please, apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:50:21 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows In-Reply-To: <044.d631d36f93220766b68ac911126e9f93@haskell.org> References: <044.d631d36f93220766b68ac911126e9f93@haskell.org> Message-ID: <059.c12f2ceb71085632f9d054fadd44b47c@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * Attachment "av_diagnostics_improvement.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:50:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:50:40 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.ccb39ebe6ea63f3d3c3aa1dc8c4b614d@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > When that kind is TYPE (RepRep Int), the code generator throws up its arms in despair. So presumably the Lint check that every argument is not levity-polymorphic fails? Actually seeing the code fragment would be helpful. Assuming it's a Lint failure (which I think it could be), can't the type checker just normalise before spitting out the argument code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:50:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:50:59 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows In-Reply-To: <044.d631d36f93220766b68ac911126e9f93@haskell.org> References: <044.d631d36f93220766b68ac911126e9f93@haskell.org> Message-ID: <059.2364e0fd729ebfa2f36f286d483c1a1e@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 08:53:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 08:53:01 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.4683f1684011d94ce0ec73cb1bb94efe@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): I agree with comment:10. Let's fix this. Reid do you know how to proceed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 09:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 09:03:00 -0000 Subject: [GHC] #13107: Negative literal equal to minBound gives a spurious warning In-Reply-To: <044.def8d2f70cdee29238a18619ccf0af74@haskell.org> References: <044.def8d2f70cdee29238a18619ccf0af74@haskell.org> Message-ID: <059.eb444c092e1079304e4db0bd9f3e674d@haskell.org> #13107: Negative literal equal to minBound gives a spurious warning -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I can avoid the warning if I use the `NegativeLiterals` language pragma. Maybe that language pragma should be a candidate for inclusion as a default for the next haskell language standard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 09:11:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 09:11:19 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.e284ef254ccf596a52582a31bab2e8ca@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Is there some way to make this tracking more robust? Yes: (1) and (2) are precisely about ensuring that when something is supposed to be evaluated, it really is. > Is there a reason not to make exprOkForSpeculation more lenient for reallyUnsafePtrEquality# No, no big reason. We could consult the primops strictness info; or we could have a special case in `CoreUtils.app_ok`. -------- HOWEVER, in answering this question I also came across this (in `CoreUtils`): {{{ Note [dataToTag speculation] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Is this OK? f x = let v::Int# = dataToTag# x in ... We say "yes", even though 'x' may not be evaluated. Reasons * dataToTag#'s strictness means that its argument often will be evaluated, but FloatOut makes that temporarily untrue case x of y -> let v = dataToTag# y in ... --> case x of y -> let v = dataToTag# x in ... Note that we look at 'x' instead of 'y' (this is to improve floating in FloatOut). So Lint complains. Moreover, it really *might* improve floating to let the v-binding float out * CorePrep makes sure dataToTag#'s argument is evaluated, just before code gen. Until then, it's not guaranteed }}} The plot thickens. When I wrote this I clearly intended that (contrary to (2)) Core would ''not'' guarantee that the argument to `dataToTag#` is evaluated. Instead, we arrange that it is evaluated to being with; accept that may not be true forever; but re-establish it in `CorePrep` if necessary. That is indeed a viable path. Moreover, the first bullet of the above Note is persuasive: guaranteeing evaluated-ness is quite hard! But if we follow that path (an ''alternative'' to the to-dos in comment:21), then we should do consistently: * Ensure that `exprOkForSpeculation` on ''any'' primop does not look at lifted arguments (like the current special case for `dataToTag#`) What about strict constructors? We could use `CorePrep` to ensure that arguments to strict constructors are evaluated, just as we do for `dataToTag#`. But for `dataToTag#` the actual argument must be a pointer to the evaluated object, otherwise `dataToTag#` will fail (give a bogus answer). But for strict constructors all we care about is that the argument has been evaluated (a semantic property), and that is ensured by the wrapper. To be sure, a bogus Core-to-Core pass could apply the constructor to a non-evaluated argument, but nothing would actually go wrong. So arguably it'd be redundant to add extra evals in `CorePrep`. The third to-do in comment:21 would still be useful. Knowing evaluated- ness is always a good thing. Bottom line: this alternative path looks attractive. In summary it would entail * Treating all primops with boxed arguments like `dataToTag#` in `exprOkForSpeculation`. * Documenting the reasoning along the lines above. * Make worker/wrapper produce eval'd flags on the wrapper for CPR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 09:48:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 09:48:56 -0000 Subject: [GHC] #13109: CUSK improvements Message-ID: <046.19ae04c2da59427623532feabc0338e7@haskell.org> #13109: CUSK improvements -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Inspired by looking at `RnTypes.bindLHsTyVarBndr`, and driven by #11592, Richard and I decided to make some improvements to the treatment of CUSKs. Here's a scrappy Skype dump as a memory-jogger; it is a memory-jogger, not a full description. Richard has notes too {{{ Richard Eisenberg: data F (x :: B a) data G (x :: C b) You have written a complete user-suppled kind signature, but the following variable is undetermined: a0 :: A Perhaps add a kind signature. Inferred kinds of user-written variables: b :: B a0 x :: C b SPJ claim: CUSKs should be handled INDIVIDUALLY and in isoloation, just like term-level type signatures SPJ claim: get rid of the "after the ::" side condition for data types (last bullet of HsDecls Note about CUSKs All of this should mean (SPJ claims) no need for dep_vars returns by bindHsQTyVar, bindLHsTyVarBnrds etc ToDo: clarify comments etc in bindLHStyVarBndr Related to D2914 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 09:49:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 09:49:16 -0000 Subject: [GHC] #13109: CUSK improvements In-Reply-To: <046.19ae04c2da59427623532feabc0338e7@haskell.org> References: <046.19ae04c2da59427623532feabc0338e7@haskell.org> Message-ID: <061.819e7eebd9ceec151a05e239be518312@haskell.org> #13109: CUSK improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 10:16:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 10:16:27 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.4e92c32876270d23cb97143d017c6341@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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 rwbarton): I think so. My plan is to proceed as in 608cad595c033ba89e757c8f61a9b791a7085367 though of course it still needs explanation and tests. The new code is basically copied from `tcRnImports` where it loads orphan modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 10:37:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 10:37:58 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.28c24228ca6b7d530895de45ee3fd620@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 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 awson): #13108 could help, perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 10:38:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 10:38:24 -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.e69ebf1875093ee8f6fee23afa9ed5ed@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Unfortunately my claim > Anyone who does use the `GHC.LargeTuple` type family instances (even indirectly through another module) will have `GHC.LargeTuple` as a "family instances" import of their module turns out not to be true. The family instances imports of a module are calculated from its imports, and at that point we don't know whether the module will mention any large tuples. For the same reason putting type family instances in a module where a wired-in thing lives is a dangerous thing to do in general, since we might read the wired-in module and learn about its instances and then use them without tracking their origin. (I found #13102 while writing the previous sentence.) I don't know whether there are existing occurrences of this in base, but it's exactly what I wanted to add. Note that adding an `import GHC.LargeTuple ()` to Prelude is not a complete solution either, since a module using large tuples and their Generic instance could have `-XNoImplicitPrelude`. So I don't have a solution that I'm really happy with here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 10:47:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 10:47:44 -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.0323fbea24302efa6d3255980f53c353@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:3 simonpj]: > Aha! You are right! The relevant ticket is #2182. One thing unsaid there is that non-orphan instances cannot be a problem because the module defining a non-orphan instance must be in the transitive closure of modules below the one being compiled. It's just orphan modules that we need to take care about. So the logic here is: a non-orphan (class or type family) instance is one which is either an instance of a class/family defined in the same module or an instance that mentions a type constructor defined in the same module. Either way, in order to use the instance both the class/family and the type constructor must be in scope, so we must have actually imported them (rather than obtained them through leakage from compiling another module). The last step is not entirely true since the type constructor might also be in scope by virtue of being a wired-in type that corresponds to Haskell syntax, like a tuple. Then I don't actually have to import anything to be able to write the type. If the module `W` defining a wired-in thing defines an instance of a class defined in another module for that thing, a user program could see the instance without having to import `W`. I don't know whether this currently occurs in base (it seems to at least not happen for type families), but it's what I wanted to add in #13072. Not saying this should block adoption of the cunning plan, just that it is another wrinkle to be aware of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 11:28:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 11:28:49 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.97cf7c49f869d94930980119d06cc2c4@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: It looks like we already try to implement 1 (Note `[Export hash depends on non-orphan family instances]`). I'll investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 12:07:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 12:07:39 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.abea85164765911c1bad437ddc103955@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- 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): On all of this stuff please consult Edward. He's much more up to speed on it than I am. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 12:16:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 12:16: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.3ab3396916e75c0347c46de8824569cc@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There are several issues here. Let's focus on external packages for now. By "instance" I mean type-class instance or family instance. 1. Ensuring we have ''enough'' instances. That is, have we loaded `M.hi`, and hence added its instances into the `eps_inst_env`? * For non-orphan instances, that's guaranteed. * Note that it's guaranteed even for wired-in type constructors because we do the `checkWiredInTyCon` or `ifCheckWiredInThing`. * For orphan instances we need to take care; I think we just aggressively load all orphan modules. 2. Ensuring we do not have ''too many'' instances. When doing instance lookup we don't want to "see" any instances that are not transitively below us. * Again this is guaranteed for non-orphan instances. * For orphan instances we use the cunning plan in comment:2. * Wired-in things are below everything so I think it's a non-issue. 3. Checking family-instance consistency. Here I am not so clear, but we should write down the plan. Does that taxonomy help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 12:18:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 12:18:03 -0000 Subject: [GHC] #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.91d32442640bb2b926d8a37b043bf082@haskell.org> #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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 GordonBGood): Replying to [comment:19 simonpj]: > > As I have stated, I believe there are many use cases, even to the common worker/wrapper pattern that seeks to reduce the amount of parameter passing by enclosing a recursive worker closure inside a wrapper; any gains from this pattern could be cancelled and more if the wrapped enclosure is less efficient. > > Let me say what I ''think'' you are saying. Consider > {{{ > f x p q = let g y = ...g y'...x... > in (g p, g q) > }}} > Left as-is we allocate a closure for `g` every time we call `f`. But instead we could lambda-lift `g`: > {{{ > g2 x y = ...g2 x y'...x... > > f x p q = (g2 x p, g2 x q) > }}} > Now we don't allocate a closure for `g`. That is good. Is this what you mean? > > We don't want to do this in general, early in optimisation, because we get huge benefits from being able to "see" the binding site of `g`'s free variable `x`. But these benefits are over when it comes to code generation. > > So we have experimented with so-called "late lambda lifting" (LLF). There's a whole wiki page about it: [wiki:LateLamLift]. It can be a real win. > > One obstacle to LLF is, ironically, that it can destroy join points (see the wiki page). A second benefit of Luke's new join-point work is that it becomes much easier to ensure that LLF doesn't destroy join points, and thus renders it much more practical. I think Luke will turn his attention to it once join points are solidly in. Yes, Simon, I manually lifted the closure by turning all the otherwise free variables into arguments to the function; although I didn't actually move the code to the top level it could have been, as it is no longer a closure capturing free variables but rather just a free function. However, my point in doing so was not to show that even this early manual lambda lifting is effective but that the code generated inside the function became so much more efficient due to seeing the Loop Invariant Code Flow (LICF) and lifting the register loading outside of the loop; in my mind the compiler should have done this whether the code was a closure or not. As the article on lambda lifting says, this lambda lifting at an early stage can prevent some optimizations in some cases, and definitely there will be some cost in this case in run time overhead in passing all of those extra arguments to the function each and every time the function is called; however, as the recursive calls are eliminated by the tail call optimization of making a loop internal to the function, the function only gets called very few times so as to have a negligible overall impact here. There may be other negative effects of the very early lambda lifting, but again they are negligible compared to the gains made in efficiency of the internal loop due to properly using LICF lifting. So the question I pose is "Why isn't LICF lifting used for the code internal to closures when it is used for non-closures?". Your Lambda Lifting and Join Point Analysis can serve to reduce this problem by eliminating closures, but the problem is still there for cases where the closures can't be eliminated and/or shouldn't be lifted. I sometimes wonder whether this is the problem that makes LL and JPA appear to be so effective: this problem makes the code that doesn't use JPA/LL much slower than it would otherwise be so that if this problem were not there, the gains made from LL/JPA in eliminating some/many closures would not likely be so great. I brought up the wrapper/worker pattern because its whole point is to reduce the number of passed parameters that need to be tail call optimized away, but the "worker" then must needs be a closure; with the problem of this issue, in many cases the resulting wrapper/worker will be slower than if we didn't factor in the closure "worker". In the sieve code of this thread, the "nxtc" closure as originally written is essentially a "worker" to the "nxtp" wrapper function and manually lifting it as I did means it is no longer a "worker". I should have gotten slightly worse performance in doing this but instead got much better performance because the compiler now did LICF optimization on the non-closure, where it currently doesn't seem to be able to do it on a non-closure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 12:27:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 12:27: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.306a106f050f190eb2247b2ada1e1884@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Wired-in things are below everything Right, so this becomes a constraint that we have to adhere to under this plan. And it's a constraint I was intending to violate with the large tuples Generic stuff (tuples are wired-in, and I was going to use `deriving Generic` in the module that defines them). I'm not so happy with that exact idea any more for other reasons, so probably it shouldn't stop us from this plan. > Checking family-instance consistency. Here I am not so clear, but we should write down the plan. I started writing up the plan in d6fd7922332a16fb958d3bf2c21ed792d12c98a7. Note that there is another point related to your item 2 here, in that (at least in principle) we should only check consistency of the new instances with the instances we transitively import, not any old instances we happen to know about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 13:48:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 13:48:19 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.cc5a02b44896421d27e2b26d0c1f5882@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, the levity-polymorphism check sees the problem and reports a type of kind `TYPE (RepRep Int)` as levity-polymorphic. I will have a note in the manual about this. If the type checker didn't catch it, it would be a lint error, yes. I don't think it's as simple as a normalisation step in the type checker. For example: {{{ foo :: forall (a :: TYPE (RepRep Int)). a -> a foo x = x }}} In this code, `x` has type `a`. What's to normalise about that?? Now we could say that `x :: a |> co` where `co :: TYPE (RepRep Int) ~ TYPE IntRep`. But now `x`'s type has changed and that means we need to use casts wherever `x` has been used. And this is an easy case where the type checker can see the correct, normalised type from the get-go. In general, unification and type family reduction may be necessary before we can proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:01:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:01:49 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.7f21f017224c0cff443c78ddd7335643@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I was thinking of this as an adjunct to the LP test in the desugarer. If the argument of an application has type `ty :: TYPE k`, and `k` does not pass the LP test (yet), then normalise `k` (using top level instances only) and cast the arg wtih a coercion `TYPE k ~ TYPE k_norm`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:04:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:04:03 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.e67ff40deccf322219a17a673e88dc72@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But that means the argument would change type from `ty` to `ty |> co`. Other bits of the expression might have to change, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:07:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:07:20 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.3b444bbdf5181dd428ea34e17e102d5a@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sure. Instead of `f e` we'd have `f (e |> co)`. That's fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:21:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:21:04 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.be87cafa0e53da1382b3aa5a06dbf27b@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But if `f e` is well-typed, then `f (e |> co)` surely isn't. We would need `(f |> co') (e |> co)` or some such. I imagine this is what we'll have to do, but it doesn't seem trivial. The other possibility may be to normalise types as we're converting to Stg, where types don't matter. This poses other challenges, in that the levity-polymorphism checks in the desugarer and in Core Lint will have to distinguish between type family applications that can reduce and those that can't. Might be easier than the program transformation, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:44:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:44:12 -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.8fd0a57f507acec5c2d6577ed4c76dc3@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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:46:13 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.753be3ff8e5b5200f850714783e143bb@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- 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 the problem is that (1) doesn't go far enough: it incorporates into the hash the list of orphan modules that we transitively hash, but NOT the actual LHSes of the type family instances. So #12723 handles if we rename a module, but not if we change an LHS (which can also invalidate a consistency check.) As always with these sorts of bugs, a failing test case helps a lot! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:54:16 -0000 Subject: [GHC] #12994: Module and export level signature thinning in Backpack In-Reply-To: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> References: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> Message-ID: <060.2532cfae239efcb4e2e387ef717f81ba@haskell.org> #12994: Module and export level signature thinning in Backpack -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5f9c6d2a91ac710e7b75cfe50a7a8e84cc9ae796/ghc" 5f9c6d2a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f9c6d2a91ac710e7b75cfe50a7a8e84cc9ae796" Support for using only partial pieces of included signatures. Summary: Generally speaking, it's not possible to "hide" a requirement from a package you include, because if there is some module relying on that requirement, well, you can't just wish it out of existence. However, some packages don't have any modules. For these, we can validly thin out requirements; indeed, this is very convenient if someone has published a large signature package but you only want some of the definitions. This patchset tweaks the interpretation of export lists in signatures: in particular, they no longer need to refer to entities that are defined locally; they range over both the current signature as well as any signatures that were inherited from signature packages (defined by having zero exposed modules.) In the process of doing this, I cleaned up a number of other things: * rnModIface and rnModExports now report errors that occurred during renaming and can propagate these to the TcM monad. This is important because in the current semantics, you can thin out a type which is referenced by a value you keep; in this situation, we need to error (to ensure that all types in signatures are rooted, so that we can determine their identities). * I ended up introducing a new construct 'dependency signature; to bkp files, to make it easier to tell if we were depending on a signature package. It's not difficult for Cabal to figure this out (I already have a patch for it.) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2904 GHC Trac Issues: #12994 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:54:16 -0000 Subject: [GHC] #13066: Backpack doesn't check for fixity consistency In-Reply-To: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> References: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> Message-ID: <060.ee8be5142d03d6d709845cea6fb0d3bd@haskell.org> #13066: Backpack doesn't check for fixity consistency -------------------------------------+------------------------------------- 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:D2919 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"e41c61fa7792d12ac7ffbacda7a5b3ba6ef2a267/ghc" e41c61f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e41c61fa7792d12ac7ffbacda7a5b3ba6ef2a267" Improve Backpack support for fixities. Summary: Two major bug-fixes: - Check that fixities match between hsig and implementation - Merge and preserve fixities when merging signatures Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2919 GHC Trac Issues: #13066 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:54:16 -0000 Subject: [GHC] #13041: Type classes in Backpack signatures are dodgy In-Reply-To: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> References: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> Message-ID: <060.8df52e2c15f633f38bb1033c7bad0902@haskell.org> #13041: Type classes in Backpack signatures are dodgy -------------------------------------+------------------------------------- Reporter: ezyang | 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:2925 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5def07fadd386a7a7c3a12963c0736529e377a74/ghc" 5def07f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5def07fadd386a7a7c3a12963c0736529e377a74" Revamp Backpack/hs-boot handling of type class signatures. Summary: A basket of fixes and improvements: - The permissible things that one can write in a type class definition in an hsig file has been reduced to encompass the following things: - Methods - Default method signatures (but NOT implementation) - MINIMAL pragma It is no longer necessary nor encouraged to specify that a method has a default if it is mentioned in a MINIMAL pragma; the MINIMAL pragma is assumed to provide the base truth as to what methods need to be implemented when writing instances of a type class. - Handling of default method signatures in hsig was previously buggy, as these identifiers were not exported, so we now treat them similarly to DFuns. - Default methods are merged, where methods with defaults override those without. - MINIMAL pragmas are merged by ORing together pragmas. - Matching has been relaxed: a method with a default can be used to fill a signature which did not declare the method as having a default, and a more relaxed MINIMAL pragma can be used (we check if the signature pragma implies the final implementation pragma, on the way fixing a bug with BooleanFormula.implies, see #13073) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2925 GHC Trac Issues: #13041 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:54:16 -0000 Subject: [GHC] #13073: BooleanFormula implies is wrong In-Reply-To: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> References: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> Message-ID: <060.d280a1aaf99e3a80986548843a5ddb88@haskell.org> #13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.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): Phab:D2925 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5def07fadd386a7a7c3a12963c0736529e377a74/ghc" 5def07f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5def07fadd386a7a7c3a12963c0736529e377a74" Revamp Backpack/hs-boot handling of type class signatures. Summary: A basket of fixes and improvements: - The permissible things that one can write in a type class definition in an hsig file has been reduced to encompass the following things: - Methods - Default method signatures (but NOT implementation) - MINIMAL pragma It is no longer necessary nor encouraged to specify that a method has a default if it is mentioned in a MINIMAL pragma; the MINIMAL pragma is assumed to provide the base truth as to what methods need to be implemented when writing instances of a type class. - Handling of default method signatures in hsig was previously buggy, as these identifiers were not exported, so we now treat them similarly to DFuns. - Default methods are merged, where methods with defaults override those without. - MINIMAL pragmas are merged by ORing together pragmas. - Matching has been relaxed: a method with a default can be used to fill a signature which did not declare the method as having a default, and a more relaxed MINIMAL pragma can be used (we check if the signature pragma implies the final implementation pragma, on the way fixing a bug with BooleanFormula.implies, see #13073) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2925 GHC Trac Issues: #13041 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:54:16 -0000 Subject: [GHC] #10262: Improve documentation of module signatures In-Reply-To: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> References: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> Message-ID: <062.cb2a5dff0980ce6d06972eb2a6abf2e3@haskell.org> #10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2918 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"8744869e3cb4a82b88e595c55f1fcc9ea1e6d0b7/ghc" 8744869e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8744869e3cb4a82b88e595c55f1fcc9ea1e6d0b7" Rewrite module signature documentation. Signed-off-by: Edward Z. Yang Test Plan: none Reviewers: bgamari, simonpj, austin, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2918 GHC Trac Issues: #10262 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:56:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:56:19 -0000 Subject: [GHC] #12994: Module and export level signature thinning in Backpack In-Reply-To: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> References: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> Message-ID: <060.12875ac7e9d074c9033b4d89006ae854@haskell.org> #12994: Module and export level signature thinning in Backpack -------------------------------------+------------------------------------- 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:56:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:56:29 -0000 Subject: [GHC] #13041: Type classes in Backpack signatures are dodgy In-Reply-To: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> References: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> Message-ID: <060.f2db5b8bbc8189944cb51a9669033778@haskell.org> #13041: Type classes in Backpack signatures are dodgy -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | 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:2925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:56:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:56:40 -0000 Subject: [GHC] #13073: BooleanFormula implies is wrong In-Reply-To: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> References: <045.abf16f6ff1c2c4d0a660196379705456@haskell.org> Message-ID: <060.2065ed8f2620a7c689a6b0a0e1be1ef2@haskell.org> #13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:56:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:56:48 -0000 Subject: [GHC] #13066: Backpack doesn't check for fixity consistency In-Reply-To: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> References: <045.73ce7e6f6b4e6a89b41d83bade637879@haskell.org> Message-ID: <060.b6d52273dd35280d94e7485630c5343e@haskell.org> #13066: Backpack doesn't check for fixity consistency -------------------------------------+------------------------------------- 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:D2919 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:56:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:56:56 -0000 Subject: [GHC] #10262: Improve documentation of module signatures In-Reply-To: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> References: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> Message-ID: <062.2461ff2d5395eb0b15cf822d6334fa46@haskell.org> #10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2918 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 14:58:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 14:58:37 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows In-Reply-To: <044.d631d36f93220766b68ac911126e9f93@haskell.org> References: <044.d631d36f93220766b68ac911126e9f93@haskell.org> Message-ID: <059.7afc039a08cc3b10e7fc7670a860d5c3@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Windows | 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): * cc: RyanGlScott, Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 15:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 15:08:18 -0000 Subject: [GHC] #12972: Missed specialisation opportunity with phantom type class parameter? In-Reply-To: <049.64f963aad64381fca27b6f57df680357@haskell.org> References: <049.64f963aad64381fca27b6f57df680357@haskell.org> Message-ID: <064.ab1dde077a0a34b90fd044df16bf3c62@haskell.org> #12972: Missed specialisation opportunity with phantom type class parameter? -------------------------------------+------------------------------------- Reporter: mpickering | 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): Matthew: this is a rather odd case. Look at `test4`. We have a Wanted constraint `[W] Phantom x0 Int`, where `x0` is a unification variable. But what is `x0`? We can use functional dependencies to get TWO derived constraints: 1. From the given `[G] Phantom x Int`, we get `[D] x0 ~ x`. 2. From the top-level `instance Phantom Char Int`, we get `[D] x0 ~ Char`. GHC chooses one of these arbitrarily. If it chooses (2) we unify `x0 := Int`, and solve the constraint from the top-level instance. The given constraint is not used. We get nice efficient code. But if it chooses (2) it'll unify `x0 := x`, and solve the wanted constraint from the given one, which is passed as a paramter to `test4`. That's less efficient. But you set up this situation, by providing two places to solve the constraint: from the passed-in givens, or from a top level instance. Just give a simpler type signature `test4 :: Int`. It's bit similar with `test3`. Again there are two ways to solve the wanted constraint: from the top-level instance or from the passed-in given. I'm not inclined to lose sleep over all this, unless you have a compelling use-case. --------- danharaj: I think you are describing an entirely different problem. Could you make a reproducible test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 15:39:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 15:39:56 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.aa1fde27eb81791a5584343556edc982@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- 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 not sure whether you meant LHS rather than RHS; in any case the consistency check depends on both. > As always with these sorts of bugs, a failing test case helps a lot! OK, I'll add a failing test case and then probably release the ticket. (But not immediately.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 17:23:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 17:23:12 -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.d0ca25300bccd0ad11ba414993abaa46@haskell.org> #13072: Move large tuples to a separate module in base -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: 8.2.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 int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 18:58:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 18:58:04 -0000 Subject: [GHC] #13100: Instability in 8.0.2 on 32-bit Windows In-Reply-To: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> References: <046.73ed35798281c021ccc3c6d664ed2fef@haskell.org> Message-ID: <061.c291657bb38f126fcd1d9fcd7a49cecd@haskell.org> #13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.3 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 bgamari): * status: new => closed * resolution: => fixed Comment: The 8.0.2 Windows builds were released with an unfortunate ad-hoc patch (b0dccaccb304541e7f56d702bfbf65e18b98c05d) reverting the inadvertent change. The patch is present in the `ghc-8.0` branch so this should be fixed in a future 8.0.3 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 20:32:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 20:32:48 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.b5a284cca30a631f15e2534fea218004@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: 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): The proposal is incomplete. For it to work, we would need to extend `Exp`, `Pat` and `Type` with constructors mimicking what `HsSpliced` does in the GHC AST. This is ok for producing code with splices inside brackets, but what about pattern mathing `Exp` values? To be comprehensive of all cases, the following code {{{ case e of TupE [LitE _, LitE _] -> ... _ -> ... }}} would need to be rewritten {{{ case e of TupE [ LitE _, LitE _] -> ... TupE [ LitE _, SplicedE _ (LitE _)] -> ... TupE [SplicedE _ (LitE _), LitE _] -> ... TupE [SplicedE _ (LitE _), SplicedE _ (LitE _)] -> ... _ -> ... }}} It could be alleviated with view patterns like {{{ case e of TupE [ dropSplicedE -> (LitE _), dropSplicedE -> (LitE _)] -> ... _ -> ... where dropSplicedE (SplicedE _ e) = e dropSplicedE e = e }}} but is it tolerable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 21:11:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 21:11:33 -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.4119552e77bb06d580714c48380606a2@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 nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 21:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 21:18:21 -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.fb0ab4588ec709af256b0ff65c5fe43e@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: | -------------------------------------+------------------------------------- Comment (by nomeata): In the blog post you write > Let’s change (“eta-expand”) the poll code as if then had arity 4, without actually changing then or thenIO or their runtime arities: and that this fixes the space leak. Isn’t this eta-expansion exactly what the state hack is about? So why does it not not work here? Ah, becuase `poll` is not at type `IO a` but rather for an arbitrary `Monad`… yeah, then it’s harder. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 21:52:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 21:52:20 -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.68ebcbc80800e7b59baf000715d92ee7@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: | -------------------------------------+------------------------------------- Comment (by Feuerbach): I thought that the state hack doesn't change the arity of functions, just marks them single-entry. Also, I don't think ghc needs the state hack to figure out the correct arity (in the non-polymorphic case), since it can see through the newtypes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 22:09:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 22:09:28 -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.80586d3341c1e54ecdc1b00d33a490dd@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: | -------------------------------------+------------------------------------- Comment (by nomeata): > I thought that the state hack doesn't change the arity of functions, just marks them single-entry. That’s how it works, but the ultimate goal of the state hack (the way I see it) is to eta-expand them. Usually this works by treating a `State#`-typed lambda as one-shot: {{{ foo = bar x >> baz y }}} will, after inlining `>>` (if that happens, but it usually does for IO) look like this: {{{ foo = let a = bar x b = baz y in \s0 -> case a s0 of (_,s1) -> b s1 }}} which is usually bad because of the allocations of `a` and `b`. (But I say “usually” because it is good if `bar x` is expensive and `foo` is used many times – these are the instances when people complain about the state hack removing this sharing). Now because `s0` is treated as one-shot, two optimizations are enabled, both of which have ultimately the same effect: * The inliner feels empowered to inline `a` and `b` into the lambda, because it is one shot. Then we obtain {{{ foo = \s0 -> case bar x s0 of (_,s1) -> baz y s1 }}} which we want. * The arity analysis uses the one-shot information on the lambda to determine that `foo` has arity 1 and eta-expands it: {{{ foo = \s -> (let a = bar x b = baz y in \s0 -> case a s0 of (_,s1) -> b s1) s }}} which then gets simplified to {{{ foo = \s -> case bar x s of (_,s1) -> baz y s1 }}} again. I once had an idea for a less intrusive state hack variant which would do this eta-expansion directly (but otherwise do not meddle with the one- shotness of `State#`-typed lambdas, which can be wrong), but did not follow through with it. See [ticket:9388#comment:6] for some background. But this is all `State#`-specific, while your bug is about abstractly monad code, where the compiler may now use knowledge about `IO`’s bind, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 22:10:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 22:10:38 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints In-Reply-To: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> References: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> Message-ID: <062.a37f8cc0ccb5a853e1b34f696b6ca7d7@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: initTc Operating System: 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): Probably a dup of #12921 (which I have not yet examined). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 22:38:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 22:38:02 -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.4a3460a5ff41cf6b8809da1c3db7ee3d@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 11 22:54:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jan 2017 22:54:33 -0000 Subject: [GHC] #13093: Runtime linker chokes on object files created by MSVC++ (was: Runtime linker chokes on LLVM function on Windows) In-Reply-To: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> References: <050.05198afb02a92da2a0b1a95e6841e8db@haskell.org> Message-ID: <065.8b8b8a508a26b260c449ee61bc97f350@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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:00:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:00:45 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd Message-ID: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 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)` that the majority of the memory usage I'm seeing comes from address `0x0000000200000000` which is where the RTS allocates memory AFAIK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:01:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:01:36 -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.af4666d15d94e7afca74aca81f1e23bb@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 DanielG): * Attachment "Leaky.hs" added. Test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:04:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:04:07 -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.e63d364c776cf9225723399bcaf007c9@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 DanielG: @@ -43,3 +43,3 @@ - process with `pmap $(pgrep Leaky)` that the majority of the memory usage - I'm seeing comes from address `0x0000000200000000` which is where the RTS - allocates memory AFAIK. + 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 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. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:05:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:05:00 -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.468934b0fd175c26766ece8af04186ed@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 12918 | Blocking: Related Tickets: #5462, #9968, | Differential Rev(s): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D2961 Comment: A WIP attempt at fixing this is at Phab:D2961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:05:35 -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.8ce64191c2e86d0869f03c6f1d283d64@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: 12918 | Blocking: Related Tickets: #5462, #9968, | Differential Rev(s): Phab:D2961 #12144 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => patch * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:05:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:05:58 -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.981270575dc590a6511a0edb5db9bd44@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2961 Comment: A WIP attempt at fixing this is at ​Phab:D2961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:06:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:06:28 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.1af94fbbe62f93e50243486bbb4400e2@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2961 * milestone: => 8.2.1 Comment: A WIP attempt at fixing this is at ​Phab:D2961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:07:01 -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.99a3207ba4893480e2190ac3d05321d6@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2961 * milestone: => 8.2.1 Comment: A WIP attempt at fixing this is at ​Phab:D2961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:38:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:38:11 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.0a514fe9ce06779427a0b201d2c465e3@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Two things: 1. osa1, I can't seem to reproduce the error you originally reported in this ticket on GHC 8.0.1, 8.0.2, or HEAD. 2. On GHC HEAD, I noticed that the package fails to build with `-dcore- lint` on: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** : warning: In the expression: I# (reallyUnsafePtrEquality# @ a x_a1B9 y_a1Ba) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ a x_a1B9 y_a1Ba *** Offending Program *** ... ptrEq [InlPrag=NOINLINE] :: forall a. a -> a -> Bool [LclIdX, Arity=2] ptrEq = \ (@ a_a1Dh) (x_a1B9 :: a) (y_a1Ba :: a) -> case x_a1B9 of x_X1Bi { __DEFAULT -> case y_a1Ba of y_X1Bk { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a x_a1B9 y_a1Ba)) lvl_s1QL } } }}} Possibly related to #13027? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:43:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:43:20 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.af1c78173a2f1dbaad38cac64facdfe0@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be precise, here's the portion of `atomic-primops` that fails with a Core Lint error: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} module AtomicPrimops where import GHC.Exts {-# NOINLINE ptrEq #-} ptrEq :: a -> a -> Bool ptrEq !x !y = I# (reallyUnsafePtrEquality# x y) == 1 }}} {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -O2 Bug.hs[1 of 1] Compiling AtomicPrimops ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** : warning: In the expression: I# (reallyUnsafePtrEquality# @ a x_a2OY y_a2OZ) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ a x_a2OY y_a2OZ *** Offending Program *** lvl_s3TE :: Int [LclId] lvl_s3TE = I# 1# ptrEq [InlPrag=NOINLINE] :: forall a. a -> a -> Bool [LclIdX, Arity=2] ptrEq = \ (@ a_a3I6) (x_a2OY :: a) (y_a2OZ :: a) -> case x_a2OY of x_X2P2 { __DEFAULT -> case y_a2OZ of y_X2P4 { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a x_a2OY y_a2OZ)) lvl_s3TE } } $trModule_s3TA :: TrName [LclId] $trModule_s3TA = TrNameS "main"# $trModule_s3TB :: TrName [LclId] $trModule_s3TB = TrNameS "AtomicPrimops"# $trModule :: Module [LclIdX] $trModule = Module $trModule_s3TA $trModule_s3TB *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:43:23 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.2fa5c8c3a9b4ea51cd336c4f85a36d94@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another `reallyUnsafePtrEquality#`-related Core Lint error popped up in https://ghc.haskell.org/trac/ghc/ticket/11444#comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 00:44:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 00:44:44 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.7d0945e57175f20620b1cacefbceb469@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:6 simonpj]: > Can you make a small test case so I can see? Based on your investigation, I've constructed a small test case: {{{#!hs {-# LANGUAGE MagicHash, BangPatterns #-} module PtrEqTest where import GHC.Exts (reallyUnsafePtrEquality#, Int (..)) ptrEq :: a -> a -> Bool ptrEq !x !y = I# (reallyUnsafePtrEquality# x y) == 1 }}} This produces the following error: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** : warning: In the expression: I# (reallyUnsafePtrEquality# @ a x_a2Pv y_a2Pw) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ a x_a2Pv y_a2Pw *** Offending Program *** lvl_s3Ub :: Int [LclId] lvl_s3Ub = I# 1# ptrEq :: forall a. a -> a -> Bool [LclIdX, Arity=2] ptrEq = \ (@ a_a3ID) (x_a2Pv :: a) (y_a2Pw :: a) -> case x_a2Pv of x_X2Pz { __DEFAULT -> case y_a2Pw of y_X2PB { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a x_a2Pv y_a2Pw)) lvl_s3Ub } } $trModule_s3U7 :: TrName [LclId] $trModule_s3U7 = TrNameS "main"# $trModule_s3U8 :: TrName [LclId] $trModule_s3U8 = TrNameS "PtrEqTest"# $trModule :: Module [LclIdX] $trModule = Module $trModule_s3U7 $trModule_s3U8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 01:08:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 01:08:32 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints In-Reply-To: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> References: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> Message-ID: <062.aa7cc87c9766c85f11d6db69723054aa@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: initTc Operating System: 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): A minimal reproducible test case is: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main (main) where main :: IO () main = do cp minimal-frames-lookup-map.ps minimal-frames-lookup-map_hd.ps cp minimal-frames-lookup-map.ps minimal-frames-lookup-map_hy.ps }}} Or even more minimally: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main (main) where main :: IO () main = do cp cp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 01:12:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 01:12:55 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.e5576689b4c039f9a4f8f2ef9889d6f8@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #11444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 01:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 01:13:50 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.9f02d4961ded8035ead318364830f73b@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #13027 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 01:33:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 01:33:04 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.41beb712bbdd4b709aa3405c245f1bc7@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've trimmed the code down to just this: {{{#!hs {-# LANGUAGE OverloadedStrings #-} module LuaParser (stat) where data Parser a data Stat {-# ANN module "HLint: ignore Reduce duplication" #-} stat :: Parser Stat stat = choice [] }}} This triggers this panic on GHC 8.0.2 and HEAD: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling LuaParser ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] choice_a13R :: t_a13Q[tau:1] (CHoleCan: choice)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But disturbingly, this panic does //not// occur on GHC 8.0.1, so this is a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 01:34:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 01:34:32 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints In-Reply-To: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> References: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> Message-ID: <062.25f631faadefd51d5ec71917ea65838d@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: initTc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12921 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12921 Comment: Like #12921, this only happens on GHC 8.0.2 and HEAD, not on GHC 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 01:34:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 01:34:48 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.604cea5c4d612754d781ac9b18311762@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13106 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 03:17:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 03:17:27 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.cf7e9025171b51d73c0266d9f016ecd5@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #8763 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 03:42:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 03:42:43 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.69be340794ada07d7fbacbd90bcb60a9@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Simon's commit 1ef274298978369e2e07b5c43e635a5ca529a0af: {{{ From 1ef274298978369e2e07b5c43e635a5ca529a0af Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Thu, 13 Oct 2016 12:24:53 +0100 Subject: [PATCH] Further improve error handling in TcRn monad This patch builds on the one for Trac #12124, by dealing properly with out-of-scope "hole" errors. This fixes Trac #12529. The hard error coming from visible type application is still there, but the out-of-scope error is no longer suppressed. (Arguably the VTA message should be suppressed somehow, but that's a battle for another day.) }}} caused this (and #13106). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 06:07:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 06:07:37 -0000 Subject: [GHC] #13111: maintainer-clean should clean build.mk Message-ID: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> #13111: maintainer-clean should clean build.mk -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Build System | 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: -------------------------------------+------------------------------------- Unfortunately `maintainer-clean` doesn't clean `mk/build.mk`, which lead to bad binary distributions being distributed for 8.0.2. This needs to be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 06:56:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 06:56:31 -0000 Subject: [GHC] #13111: maintainer-clean should clean build.mk In-Reply-To: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> References: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> Message-ID: <061.fb38d9ae2467b7c50c45bbdcf2509e8d@haskell.org> #13111: maintainer-clean should clean build.mk -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Build System | 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:D2963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2963 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 08:36:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 08:36:53 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.c414394448fdceb805e23f0a826d8b7a@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I debugged this last night and I know what is going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 08:43:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 08:43:42 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# (was: Core lint errors compiling containers HEAD with GHC HEAD) In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.9b7d69d16a291b1f57cff2b21a163fd8@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 08:47:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 08:47:03 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.9e27fd2f1015f81b98bdcee378ea2db7@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha! This is closely linked to #13027; read esp comment:23 on that ticket. In that comment I quote this Note from `CoreUtils` {{{ Note [dataToTag speculation] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Is this OK? f x = let v::Int# = dataToTag# x in ... We say "yes", even though 'x' may not be evaluated. Reasons * dataToTag#'s strictness means that its argument often will be evaluated, but FloatOut makes that temporarily untrue case x of y -> let v = dataToTag# y in ... --> case x of y -> let v = dataToTag# x in ... Note that we look at 'x' instead of 'y' (this is to improve floating in FloatOut). So Lint complains. Moreover, it really *might* improve floating to let the v-binding float out }}} The remark about `FloatOut` is ''exactly'' what is happening here. So if we follow the "alternative path" described in comment:23, that'll fix this ticket too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 08:47:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 08:47:38 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.3fcf8ea80008f137ac502c2680eb28db@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, taking the "alternative path" in comment:23 will fix #11444 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 10:40:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 10:40:54 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.87e5d00583f9ad297ccff3b5c358b199@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for making this a new ticket, Ryan. Do you think you might execute on it? I can advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 10:54:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 10:54:16 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.420d6261d0f6284925f82b3a04cf30b5@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Agreed that the splitting rule must be implemented in the TH quoting mechanism. I do not agree. The business of TH is to reflect Haskell ''source'' code. In this case the Haskell source code signature is {{{ pattern P :: b -> T a }}} That generates a `LHsSigType` for the type. '''We should be able to round- trip that `LHsSigType` through TH and get back the exact same thing'''. If we do that then, because it's the exact same thing, if it typechecked before it'll typecheck after the round trip. What is happening, I think, is that we are getting back a `LHsSigType` with more explicit quantification that the original one had. That's bad! We should get back the exact same thing. I haven't dug deeper, but that must be possible, right? I think it's the ''wrong'' thing for the TH (syntax-level) conversions to attempt to figure out what is quantified where. Just reproduce what the user wrote! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 11:10:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 11:10:32 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. In-Reply-To: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> References: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> Message-ID: <063.b2741fadd3c0ac65ce8187330c953d81@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ---------------------------------+---------------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I'll close this as fixed in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 11:10:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 11:10:42 -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.8e862db5d086a8352053099749bd6add@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 rwbarton): With the caveat that I don't feel like I fully grok type checking in the middle of an import cycle, let me offer a variant on goldfire's and adamgundry's proposals: When we type check a module that has an hs-boot file (here `B.hs`), do so in the type family instance environment of `B .hs-boot`. In other words, allow type family instances in hs-boot files and require of the user that if they want to use a type family instance while compiling `B.hs`, it must already be present in `B.hs-boot`. This is more lenient than "''every'' type family in `B.hs` ''must'' be listed in `B.hs-boot`" and I think it's a clearer or at least more implementable version of adamgundry's "must list all type instance declarations used (transitively) in the typechecking of [...]". Maybe it's even exactly equivalent to that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 11:11:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 11:11:15 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.d4d66946d61c6457d2772e01a312b861@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2210 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just for the record #12789 was another example of this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 11:14:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 11:14:41 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. Message-ID: <044.8846313dfa837f257582237983583132@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 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: --------------------------------------+--------------------------------- Currently GHC HEAD segfaults on Windows 64-bit when compiling `language-c-quote-0.11.7.1` package. It spits something like `Access violation in generated code when executing data at 0000000102fbcf40` (I'm using my #13108 patch here). After repeated run, when GHC hasn't recompile all files, but only part of them, it succeeds. If I delete intermediate files and repeat clean compilation, it segfaults again. Haddock always segfaults (since it always recompile all files), more details here: https://github.com/haskell/haddock/pull/568. Since these access violations consistently happen on executable data at virtual addresses above 4GB mark, this very much smells as a GHC bytecode generator/linker issue. I believe, GHC and Haddock succeed exactly when all executable addresses stay below 4GB mark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 11:24:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 11:24:31 -0000 Subject: [GHC] #11781: Improve common sub-expression In-Reply-To: <046.d41bb7973b2b27b60de694c658d90193@haskell.org> References: <046.d41bb7973b2b27b60de694c658d90193@haskell.org> Message-ID: <061.b74b6ba3b89554f83d1e142e55ca24bb@haskell.org> #11781: Improve common sub-expression -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2074 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): For the record, the actual commit was {{{ commit 5b986a4de288e2c703c38ee37222a7bf3260cc11 Author: Simon Peyton Jones Date: Fri Apr 1 12:24:50 2016 +0200 CSE code cleanup and improvement Triggered by an observation by Joachim, Simon felt the urge to clean up the CSE code a bit. This is the result. (Code by Simon, commit message and other leg-work by Joachim) Differential Revision: https://phabricator.haskell.org/D2074 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 12:58:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 12:58:12 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints In-Reply-To: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> References: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> Message-ID: <062.ef030a5e580674454347f68b3a6309e8@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: initTc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12921 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f5f6d4237b87f5d0e3e0a05e4cfc52bb3c0e4ad9/ghc" f5f6d423/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5f6d4237b87f5d0e3e0a05e4cfc52bb3c0e4ad9" Fix top-level constraint handling (Trac #12921) Some out-of-scope errors were not being reported if anyone throws an un-caught exception in the TcM monad. That led to ghc: panic! (the 'impossible' happened) initTc: unsolved constraints I fixed this * Splitting captureConstraints to use an auxilliary tryCaptureConstraints (which never fails) * Define a new TcSimplify.captureTopConstraints (replacing the old TcRnMonad.captureTopConstraints), which reports any unsolved out-of-scope constraints before propagating the exception That in turn allowed me to do some tidying up of the static-constraint machinery, reducing duplication. Also solves #13106. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 12:58:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 12:58:12 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.36a7877703bd3e2a446608484cf1af53@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f5f6d4237b87f5d0e3e0a05e4cfc52bb3c0e4ad9/ghc" f5f6d423/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5f6d4237b87f5d0e3e0a05e4cfc52bb3c0e4ad9" Fix top-level constraint handling (Trac #12921) Some out-of-scope errors were not being reported if anyone throws an un-caught exception in the TcM monad. That led to ghc: panic! (the 'impossible' happened) initTc: unsolved constraints I fixed this * Splitting captureConstraints to use an auxilliary tryCaptureConstraints (which never fails) * Define a new TcSimplify.captureTopConstraints (replacing the old TcRnMonad.captureTopConstraints), which reports any unsolved out-of-scope constraints before propagating the exception That in turn allowed me to do some tidying up of the static-constraint machinery, reducing duplication. Also solves #13106. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 12:59:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 12:59:56 -0000 Subject: [GHC] #13106: impossible happened: initTc: unsolved constraints In-Reply-To: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> References: <047.053d1eeb552781534b3c3fedf097abcb@haskell.org> Message-ID: <062.053b9b6d7b729e003eaccf64c4a5dad4@haskell.org> #13106: impossible happened: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: initTc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12921 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 13:00:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 13:00:49 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.6c4ffa1bdbdbe55ed09dcad17f4cd8f4@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T12921 Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T12921 Comment: Merge to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 16:15:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 16:15:09 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.b37c9f30d6f17df4c78dccffddf12096@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 simonpj]: > Thanks for making this a new ticket, Ryan. Do you think you might execute on it? I can advise. Certainly! And since you extended the offer for advice... I could certainly use it :) Some questions that pop into my head: 1. Where is the best place to add this check? [https://git.haskell.org/ghc.git/blob/f5f6d4237b87f5d0e3e0a05e4cfc52bb3c0e4ad9:/compiler/typecheck/TcInstDcls.hs#l1279 tc_default] in `TcInstDecls`? 2. How stringent should this check be? For instance, should this be accepted? {{{#!hs class Eq1 f where (==#) :: forall a. Eq a => f a -> f a -> Bool default (==#) :: forall b. Eq (f b) => f b -> f b -> Bool (==#) = (==) }}} These have the same tau types module `forall`'d type variable names. Should we require that the type variables be //exactly// the same, even down to the `forall`'d ones? Even in this cleaned up version: {{{#!hs class Eq1 f where (==#) :: forall a. Eq a => f a -> f a -> Bool default (==#) :: forall a. Eq (f a) => f a -> f a -> Bool (==#) = (==) }}} The `a`s get renamed behind the scenes, so it's actually closer to: {{{#!hs class Eq1 f where (==#) :: forall a1. Eq a1 => f a1 -> f a1 -> Bool default (==#) :: forall a2. Eq (f a2) => f a2 -> f a2 -> Bool (==#) = (==) }}} After renaming. 3. How do type families affect this? Currently, there's an accepted GHC testsuite test ([https://git.haskell.org/ghc.git/blob/f5f6d4237b87f5d0e3e0a05e4cfc52bb3c0e4ad9:/testsuite/tests/generics/T10361b.hs T10361b]) with this default type signature: {{{#!hs class Convert a where type Result a type instance Result a = GResult (Rep a) convert :: a -> Result a default convert :: (Generic a, GConvert (Rep a)) => a -> GResult (Rep a) convert x = gconvert (from x) }}} Should this be rejected now? That is, must you write the above like this? {{{#!hs convert :: a -> Result a default convert :: (Generic a, GConvert (Rep a), Result a ~ GResult (Rep a)) => a -> Result a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 16:20:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 16:20:06 -0000 Subject: [GHC] #11695: On GHCi prompt the arrow (movement) keys create strange character sequences In-Reply-To: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> References: <048.2c7ac4aadebf684928a9b23225097ed9@haskell.org> Message-ID: <063.e7a69df0d47453bddc122064b917ca49@haskell.org> #11695: On GHCi prompt the arrow (movement) keys create strange character sequences ---------------------------------+-------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by heisenbug): * status: infoneeded => new Comment: Looking at my previous comments it appears that the syscall `read` will (sometimes) break up `ESC` sequences (when coming through some `ssh` tunnel?), and `haskeline` chokes on bachelor `ESC`s instead of `read`ing on and combining stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 16:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 16:30:03 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.fcce708b1f4f6894d999da1d896c676f@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): 1. In `TcClassDcl.tcClassSigs`. 2. Yes, I agree it should be insensitive to alpha renaming of any locally-quantified variables. (It would be ok for it to be sensitive to order, I guess. There's a little wiggle room there.) 3. Yes I think it should be rejected. I think the alternative version you give is actually clearer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 16:33:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 16:33:59 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.0aa4c3d65d6ee12fa486632a84aa745f@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Here come the latest stats (with today's GHC HEAD) : {{{ $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.*o -rw-r--r-- 1 ggreif lb40 482568 Jan 12 16:24 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif lb40 514776 Jan 12 16:24 ./libraries/time/dist- install/build/Data/Time/Format.o $ wc -l ./libraries/time/lib/Data/Time/Format.hs 254 ./libraries/time/lib/Data/Time/Format.hs $ strip ./libraries/time/dist-install/build/Data/Time/Format.*o $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.*o -rw-r--r-- 1 ggreif lb40 201512 Jan 12 17:26 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif lb40 187712 Jan 12 17:26 ./libraries/time/dist- install/build/Data/Time/Format.o $ ghc -e "187712/254" 739.0236220472441 }}} As you can see a single line of Format.hs gets compiled to 739 stripped bytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 17:36:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 17:36:59 -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.853f5b1c18166c88c53e4ce374171def@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: | -------------------------------------+------------------------------------- Comment (by simonpj): Suppose it had been {{{ worker :: (Monad m) => m () worker = forever $ poll 1 poll :: (Monad m) => Int -> m a poll n | n>10000 = return () | otherwise = do print (expensive n) poll (n+1) }}} where `expensive` is expensive to compute. After printing out the results of 10000 calls to `expensive`, the `forever` will do it all again. Question: would you expect all the calls to `expensive` to be recomputed? Presumably not. `poll` builds a big action {{{ print (expensive 0) >> print (expensive 1) >> print (expensive 2) >> ... }}} and `forever` just repeatedly executes that action. But to remember all those results clearly takes O(n) space. Now in this case there is no real work to be shared, but that's clearly harder for GHC to spot. Especially when (as in this case) the monad is unspecified, so perhaps the call `return ()` does a tremendous amount of work. I'm not saying things can't be improved here, but you are in delicate territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 17:40:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 17:40:08 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows In-Reply-To: <044.d631d36f93220766b68ac911126e9f93@haskell.org> References: <044.d631d36f93220766b68ac911126e9f93@haskell.org> Message-ID: <059.f131952d86850302d3c2c833f3a9b104@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D2969 Comment: Thanks for the patch, awson! Note that this patch isn't entirely trivial, so in the future it'd be best to just submit it directly to Phabricator. I went ahead and submitted to Phab myself as Phab:D2969 and added you as a subscriber, so if there are changes requested, feel free to commandeer the Diff and fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 17:43:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 17:43:13 -0000 Subject: [GHC] #13113: Runtime linker errors with CSFML on Windows Message-ID: <050.1aed55ff7ea34c46ed3453501d107fdf@haskell.org> #13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another day, another runtime linker bug on Windows. This time, it's from the CSFML library (written in C++). I observed this when trying to load the [http://hackage.haskell.org/package/SFML SFML] Haskell library in GHCi. To install CSFML in MSYS2: {{{ pacman -S mingw-w64-x86_64-csfml }}} Here's the Haskell code I'm using: {{{#!hs module Main (main) where import Foreign.Ptr newtype CircleShape = CircleShape (Ptr CircleShape) deriving Show foreign import ccall unsafe "sfCircleShape_create" sfCircleShape_create :: IO CircleShape foreign import ccall unsafe "sfCircleShape_copy" sfCircleShape_copy :: CircleShape -> IO CircleShape main :: IO () main = do putStrLn "----------------------" cs1 <- sfCircleShape_create print cs1 cs2 <- sfCircleShape_copy cs1 print cs2 putStrLn "----------------------" }}} Compiling it with `ghc -lcsfml-graphics SFML.hs` on GHC 8.0.2 and HEAD seems to work fine. But if you run it in GHCi, it breaks. With GHCi 8.0.2: {{{ $ ghci -lcsfml-graphics SFML.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.exe: addDLL: csfml-graphics-2.dll (Win32 error 127): The specified procedure could not be found. ghc.exe: Could not load `csfml-graphics-2.dll'. Reason: addDLL: could not load DLL Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf [1 of 1] Compiling Main ( SFML.hs, interpreted ) Ok, modules loaded: Main. > main ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: sfCircleShape_create This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} With GHC HEAD: {{{ $ ..\..\..\Software\ghc\inplace\bin\ghci -lcsfml-graphics SFML.hs GHCi, version 8.1.20170108: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: addDLL: csfml-graphics-2.dll (Win32 error 127): The specified procedure could not be found. ghc-stage2.exe: Could not load `csfml-graphics-2.dll'. Reason: addDLL: could not load DLL Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf Ok, modules loaded: Main (SFML.o). > main ghc-stage2.exe: C:\Users\RyanGlScott\Documents\Hacking\Haskell\SFML.o: unknown symbol `sfCircleShape_create' }}} I also get the same error with Phab:D2941 (#13082) applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 18:36:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 18:36:05 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.b1337e73ba4c0d675aec2a086eeb0ded@haskell.org> #7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 18:44:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 18:44:09 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.ec647807eae952e6374d3a5515f1522c@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 19:20:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 19:20:22 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.6ddb2e0fdb78f9d9ab1b949e5169b8f7@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: infoneeded 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): I have rewrite the two functions.[[BR]] Here are simpler and concise functions.[[BR]] We understand better the rules of inference.[[BR]] {{{ mod_ponens :: Bool -> Bool -> Bool mod_ponens a b = a && implies a b mod_tollens :: Bool -> Bool -> Bool mod_tollens a b = not b && implies a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 20:11:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 20:11:51 -0000 Subject: [GHC] #13085: -fregs-graph is ignored but this is undocumented In-Reply-To: <048.179c57af2638d63782eeaa4e29c25b37@haskell.org> References: <048.179c57af2638d63782eeaa4e29c25b37@haskell.org> Message-ID: <063.8bd8c276677c9fa44eb047b993fa7361@haskell.org> #13085: -fregs-graph is ignored but this is undocumented -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: #13033, #7192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13033, #7192 Comment: Indeed `-fregs-graph` has been a bit of a state of disarray since the merge of the new code generator, at which point it regressed in performance to the point of being worse than the linear allocator in some cases (#7192). At this point the flag was disabled. tjakway has been interested in dusting it off so I tried to re-enable the flag for 8.0.2, but unfortunately this prompted #13033 which forced me to revert the change. Regardless, I hadn't noticed that `-fregs-graph` lacked documentation; thanks for pointing this out. This should be fixed for 8.2.1, when `-fregs-graph` should be finally enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 12 22:35:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jan 2017 22:35:03 -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.cf14b71940e8eee4ba59422ffcc2b0af@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: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Simon: as a matter of fact, I would expect all the calls to expensive to be recomputed. I think most programmers would interpret the above code as {{{ while (1) { for (n = 1; 1 <= 10000; n++) { print(expensive(n)); } } }}} If I wanted the calls to expensive to be shared, I would probably put them into a list. (Of course, a similar piece of code could be intended for `m = []`; but based on `print`, it looks like something intended for an `IO`-like monad.) I do understand the tradeoffs involved, and I'm not saying that this should be obvious to the compiler. I'm just saying that this might not be the most convincing example where the current behavior is the one a programmer would expect. What if a programmer could annotate variables (like `worker` or `poll`) as "function-like" vs "value-like"? "Function-like" means "I don't care about this value, feel free to recompute it" and "value-like" means "please cache it if possible". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 01:01:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 01:01:26 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.5711cfe6bba89b3919b5e8ee6b1a4ab8@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 dfeuer): * Attachment "stats-801.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 01:01:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 01:01:50 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.690cf570fd315b37b7b7e41402c69c18@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 dfeuer): * Attachment "stats-802rc2.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 03:18:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 03:18:44 -0000 Subject: [GHC] #13114: UniqSet definition seems shady Message-ID: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> #13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: 8.4.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: -------------------------------------+------------------------------------- Currently, {{{#!hs type UniqSet a = UniqFM a }}} The key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is {{{#!hs newtype UniqSet a = US (UniqFM a) }}} Unfortunately there's an awful lot of code using `UniqSet` and assuming it's the same as `UniqFM`. To make this work, we'd need to expand the `UniqSet` API somewhat and figure out what to do at use sites using it interchangeably with `UniqFM`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 03:44:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 03:44:42 -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.c505405fc6403013420db58d3247710b@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): If we write {{{#!hs foo = ... where bar = ... where baz = ... }}} do we intend for `bar` to be recomputed on each call to `foo`, or shared globally? Do we intend for `baz` to be recomputed on each call to `bar`, or on each call to `foo`, or shared globally? The compiler doesn't know. Worse, experienced Haskell developers have gotten used to the way GHC tends to float things around, so making things simpler and more predictable is likely to turn a lot of currently-good code bad. Maybe Joachim's `oneShot` can help in some places? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 06:12:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 06:12:22 -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.09e5dc489af4a39894e9c1ba6cd61b17@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: | -------------------------------------+------------------------------------- Comment (by Feuerbach): David: If `foo` is marked as function-like by the programmer, `bar` and `baz` are recomputed on each invocation of `foo`. If `foo` is marked as value-like and is shared, `bar` and `baz` are shared, too. Furthermore, `bar` and `baz` could have their own annotations. Examples: {{{#!hs {-# FUNCTION_LIKE fib #-} fib = (fibs !!) where {- VALUE_LIKE fibs #-} fibs = 0 : 1 : zipWith (+) fibs (tail fibs) }}} {{{#!hs {-# VALUE_LIKE val #-} val = sum $ map f [1..10^6] where {-# FUNCTION_LIKE f #-} f = (+5) . (^2) }}} Now, what would FUNCTION_LIKE mean, exactly? In the `fib` example above, there can be two interpretations: 1. Don't bother "remembering" the PAP `(!!) fibs`, but do remember something like `fibs !! n`. 2. Don't even remember `fibs !! n`. The second interpretation is useful in cases like {{{#!hs mk_action :: Monad m => Int -> m () mk_action = flip replicateM_ (return ()) }}} where we may want to say, "don't bother to remember either the expansion or the result of mk_action". So, simple FUNCTION_LIKE can be ambiguous. What if we annotated functions with arities? Assigning an explicit arity to a function means that: 1. ghc attempts to perform eta reductions or expansions to match the declared arity; 2. ghc doesn't float things out of lambdas with declared arity >= 1. E.g. following Reid's example (https://ghc.haskell.org/trac/ghc/timeline?from=2017-01-07T14%3A42%3A24Z&precision=second), he could write {{{#!hs poll a = r >>= f where {-# ARITY 1 f #-} f _ -> poll a }}} and ghc would not transform `f` to `(let s = poll a in \_ -> s)`. And, of course, the original problem could be easily solved by annotating `poll` with the correct arity, as I point out in the blog post. It is also possible that these two things — forcing eta-expansion and not floating out local bindings — should be two different and orthogonal pragmass. What do you all think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 07:26:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 07:26: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.2df477adeba638889ca31a67581b5d47@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): I haven't finished bisecting, but I have a bit of information to report. The allocations rose 10GB between 8.0.1 and aa6da11. They rose 68GB between aa6da11 and 5662cea. They then dropped about 15GB between there and 8.0.2rc2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 08:28:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 08:28:40 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.3cad7ae5d44fd7897af8048aa999a067@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): One last datapoint before I go to sleep: there wasn't any notable change between aa6da11 and 61be194, so the big rise was between 61be194 and 5662cea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 08:50:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 08:50:17 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.e7ad042406ea992cb5a80b4cbe0c3acb@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 MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 09:01:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 09:01:47 -0000 Subject: [GHC] #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide In-Reply-To: <042.a992a290421e0ee585b6ffd4e20279f8@haskell.org> References: <042.a992a290421e0ee585b6ffd4e20279f8@haskell.org> Message-ID: <057.baaed6e23b55c8e2deaa134068a6802a@haskell.org> #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.0.3 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by phadej): Does `-Wextra` include every other `-W...` flag? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 09:02:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 09:02:55 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.abd1ca448751beb9cb2c15785d7d5643@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6b976eb89fe72827f226506d16d3721ba4e28bab/ghc" 6b976eb8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b976eb89fe72827f226506d16d3721ba4e28bab" 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 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 10:40:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 10:40:22 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.2dcb4808b7d26f5c9a063f27550c4395@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Indeed you are right, this is not a bug in the type constraints that the checker generates but the term constraints. I expected the knownBools to be already desugared to (knownBool $dKnownBool_a) and (knownBool $dKnownBool_b) since they are overloaded but I was mistaken. I'm going to need more guidance before I can help. Can you give instructions to reproduce the bit you think is unexpected? I compiled the program (adding a definition for `Dict` which you omitted), with `-ddump-ds` and got {{{ ... ds_d3Xn = knownBool @ a $dKnownBool_a3Ux } in ... ds_d3Xo = knownBool @ b $dKnownBool_a3UL } in }}} which is what you expect. This is post-desugaring. Before desugaring there'll be a `HsWrapper` involved. Anyway, please show me specifically what you think it unexpected. ---------------- Incidentally, the constraint signatures don't seem to work. Compiling {{{ type T a = Eq a :: Constraint }}} yields a syntax error, as does {{{ type T a :: Constraint = Eq a }}} I must be doing something stupid. But what? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 10:59:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 10:59:19 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.50f1e0e842bef0db29f08711d12ab102@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by br1): * cc: br1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 11:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 11:18:57 -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.6a54fad1a6dd024b27f48c1488e950c9@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: | -------------------------------------+------------------------------------- Comment (by rwbarton): So there are three issues here: 1. The programs under discussion leak space. 2. The space leak is hard to see and unintuitive. (I didn't understand what was going on until I saw Roman's answer on SO.) 3. You can't even eliminate the space leak in a reliable way. Fixing 1 directly seems infeasible without breaking other programs, because of examples like Simon's in comment:14. Plus, the space leak does exist if you evaluate the program naively using lazy evaluation, despite 2. (And there are parallel examples that don't involve IO.) But we should be able to do something about 3, and it would be useful in many settings besides this one (such as benchmarking). I like the idea that if the user wants FUNCTION_LIKE behavior, then they should write a function. It aligns well with the basic rule for sharing (an expression inside a lambda is shared for the lifetime of that call to the lambda) and we already know how to implement it (just compile with `-O0`). We just have to not stuff it up during optimization. This is basically the full laziness problem yet again. The problem is of course that writing a function isn't sufficient because GHC will probably just float the body out. Besides that there's a second danger: we could inline and then beta-reduce. I don't want to write it out, but if you imagine inlining `>>=` and `f` in Roman's latest example, and then if you allow beta-reducing `f`, the lambda in `f` would disappear and then presumably nothing would stop GHC from floating `poll a` out of the lambda in `>>=`. It's hard to see how the inlining could be to blame here, so I blame the beta-reduction. (Then perhaps if we are never going to be allowed to beta-reduce, we can also not bother inlining. Not sure.) So, it seems to me we need a new kind of Core lambda, or a flag on lambda, that means * don't float out of this, * don't beta reduce this. How to give the user access to this is another question. I haven't thought about this `ARITY` suggestion much yet. Another possibility would be a magic pattern synonym `_#`, which matches anything but turns the lambda into a beta blocker. So then we'd write Roman's example as something like {{{#!hs import GHC.Exts (pattern _#) poll a = r >>= f where f _# = poll a }}} See also #9520, #8457. #12656 is a bit different, but it is the ticket I was prompted to remember by Roman's SO post. #12620 has a proposed solution but I think tying the "no floating" annotation to a lambda rather than an expression within the lambda might be more robust and easier to understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 11:19:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 11:19:43 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs In-Reply-To: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> Message-ID: <059.ae634bd15ff24a98b36eb0f55092b4d0@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: Type: feature request | Status: patch Priority: low | 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:D2958 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D2958 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 11:22:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 11:22:39 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.239fc59a514a9beddbd5a54a6a49ca2b@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:9 simonpj]: > > Indeed you are right, this is not a bug in the type constraints that the checker generates but the term constraints. I expected the knownBools to be already desugared to (knownBool $dKnownBool_a) and (knownBool $dKnownBool_b) since they are overloaded but I was mistaken. > > I'm going to need more guidance before I can help. Can you give instructions to reproduce the bit you think is unexpected? > > I compiled the program (adding a definition for `Dict` which you omitted), with `-ddump-ds` and got > {{{ > ... > ds_d3Xn = knownBool @ a $dKnownBool_a3Ux } in > ... > ds_d3Xo = knownBool @ b $dKnownBool_a3UL } in > > }}} > which is what you expect. This is post-desugaring. Before desugaring there'll be a `HsWrapper` involved. Ah, great, thanks! This may be sufficient: I think that `translatePat` in `deSugar/Check.hs` just needs to look at the wrapper in the `CoPat` case then. It already inspects it for dropping trivial coercions, as an optimization. I'll look into it and ping you if anything else gets in the way (I hope not). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 11:32:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 11:32:01 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs In-Reply-To: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> Message-ID: <059.4052491a4ec71dde26cea1957ec18a36@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: alanz Type: feature request | Status: patch Priority: low | 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:D2958 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 12:03:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 12:03:31 -0000 Subject: [GHC] #12417: API annotations for unboxed sums needs reworking In-Reply-To: <043.00b31e92686f5920efa6f831cd588891@haskell.org> References: <043.00b31e92686f5920efa6f831cd588891@haskell.org> Message-ID: <058.a7a1781a3bee9c3ffce6ab9f1b0e6a75@haskell.org> #12417: API annotations for unboxed sums needs reworking -------------------------------------+------------------------------------- Reporter: osa1 | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: => Phab:D2968 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 13:04:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 13:04:19 -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.4567993450af12ab76100ee2e640d679@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 awson): Well, I've slightly changed internals or runtime linker and managed to catch this segfault at address `00000000940c6da0` which is below 4GB but clearly above 2GB mark. This clarifies things somewhat, I believe, because "small" memory model code executable addresses should lie below this mark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 13:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 13:42:51 -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.c71cafa5ceb4081d4b511e73cd1d593f@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 awson): Sorry for the noise, I've deleted my previous comment since it was quite misleading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 14:07:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 14:07:51 -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.615fdfd99a51be5310d78f08c47a871f@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: | -------------------------------------+------------------------------------- Comment (by simonpj): > So, it seems to me we need a new kind of Core lambda, or a flag on lambda, that means (a) don't float out of this, (b) don't beta reduce this. We already have (a), namely one-shot lambdas. I don't understand why (b) could possibly be good. Perhaps someone can give a from-scratch articulation of the problem and possible solutions, informed by this thread? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 14:32:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 14:32:44 -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.5e246ad120cd256f61fef5844562b8fa@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: | -------------------------------------+------------------------------------- Comment (by nomeata): > do we intend for bar to be recomputed on each call to foo, or shared globally? The answer to this question depends heavily on what it means for “foo” to be called! Consider this: {{{#!hs foo :: Int -> IO () foo x = … where bar = expensive x }}} If we now run `mapM (foo 1) [1.1000]`, then, in one sense, the function `foo` is called once (when passed `x`). This returns a value of type `IO ()`, which is then executed 1000 times. This is the sense that the compiler understands, and without further hacks, `bar` would be evaluated only once here. Some users know and expect this. But there is another sense where one thinks of a call to `foo` as the execution of the `IO` action produced by `foo 1`. This is probably how most users in most cases think about functions returning an `IO` something. . With the current implementation of `IO ()`, this is when the state token is passed to the function wrapped in `IO ()`. The state hack is about eta-expanding `foo` so that these notions coincide. Unfortunately, and as far as I can tell, there is no way of writing `foo` to get this result directly (without breaking the `IO` abstraction barrier). The same distinction works for other monads, of course: `foo 1` might return a `Parser ()`, and we have the distinction between calculating the parser, and applying it to some input. And, in extension, with an arbitrary `Monad` the distinction is even more evident. So in this thread, we should be very precise which form of “calling” is the right one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 15:13:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 15:13:40 -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.0e8d7d686822d83e75f603ddedef9d57@haskell.org> #13077: Worker/wrapper can break the let-app invariant -------------------------------------+------------------------------------- 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): Here's a related one where we need to record evaluted-ness on CPR result binders {{{ data X = A | B | C data T = MkT !X Int# Int# g :: Int -> T g 0 = MkT A 1# 2# g n = g (n-1) boo :: Int -> T boo k = case g k of MkT x n _ -> let v = case x of A -> 1# B -> 2# C -> n in MkT x v v }}} Here we get a wrapper for `g` like this {{{ g x = case $wg x of (# w1, w2 #) -> MkT w1 w2 w2 }}} It's important to record that `w1` is evaluated, as the use in `boo` makes clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 15:44:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 15:44: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.f38fd3d3860c5f88510377d3b15733df@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:53 goldfire]: > Replying to [comment:46 mpickering]: > > Thanks for this detailed reply! I'm happy with all your responses save one: > > > > - The spec says "We verify that the result types of each constructor in a complete match agrees with each other." What does this sentence mean? Consider the possibility of pattern synonyms that match against functions, polymorphic patterns, and possibly even higher-rank patterns. > > > > > > > It means that we look at the result type of each conlike and then verify that the type constructor for each type is the same. In the case of a set containing polymorphic patterns, at least one pattern in the set must have a definite type or you must specify a type signature to fix the type for the whole set. > > I'm not sure what you mean here. Where do you specify the type signature? In the `COMPLETE` pragma? I updated the wiki page now with lots of examples. You can specify something like.. {{{#!hs pattern P :: Maybe a pattern P = Nothing {-# COMPLETE P :: Maybe #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 18:03:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 18:03:48 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.f4e337cb0b533a57ed99ec824e903263@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 18:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 18:09:47 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base Message-ID: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- as Defined in Foreign.Ptr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 20:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 20:18:47 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns Message-ID: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | 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: -------------------------------------+------------------------------------- This ticket is motivated by the use of `OverloadedLabels` of the [http://hackage.haskell.org/package/choice-0.2.0 choice package]. One can use a type `Choice "block"` with values `Do #block` and `Don't #block` by using `OverloadedLabels`. However, in patterns this syntax is forbidden. {{{ case block of Do #block -> ... Don't #block -> ... }}} It would be nice if overloaded labels desugared to something sensible in patterns, perhaps {{{ case block of Do ((==) (fromLabel (proxy# :: Proxy# "foo")) -> True) -> ... Don't ((==) (fromLabel (proxy# :: Proxy# "foo")) -> True) -> ... }}} `OverloadedLists` and `OverloadedStrings` could benefit from a similar solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 20:19:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 20:19:38 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns In-Reply-To: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> References: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> Message-ID: <071.7bc0ff17c11981e3522c736eb33eb470@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | 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 facundo.dominguez: @@ -18,2 +18,2 @@ - Do ((==) (fromLabel (proxy# :: Proxy# "foo")) -> True) -> ... - Don't ((==) (fromLabel (proxy# :: Proxy# "foo")) -> True) -> ... + Do ((==) (fromLabel (proxy# :: Proxy# "block")) -> True) -> ... + Don't ((==) (fromLabel (proxy# :: Proxy# "block")) -> True) -> ... New description: This ticket is motivated by the use of `OverloadedLabels` of the [http://hackage.haskell.org/package/choice-0.2.0 choice package]. One can use a type `Choice "block"` with values `Do #block` and `Don't #block` by using `OverloadedLabels`. However, in patterns this syntax is forbidden. {{{ case block of Do #block -> ... Don't #block -> ... }}} It would be nice if overloaded labels desugared to something sensible in patterns, perhaps {{{ case block of Do ((==) (fromLabel (proxy# :: Proxy# "block")) -> True) -> ... Don't ((==) (fromLabel (proxy# :: Proxy# "block")) -> True) -> ... }}} `OverloadedLists` and `OverloadedStrings` could benefit from a similar solution. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 20:21:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 20:21:10 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns In-Reply-To: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> References: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> Message-ID: <071.29b0fe50f28775135c56737dfee17577@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | OverloadedLabels OverloadedStrings | OverloadedLists Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11671 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * keywords: => OverloadedLabels OverloadedStrings OverloadedLists * related: => 11671 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 20:35:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 20:35:34 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.a9dcbf5292601d777e75d3471274805c@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I suppose you'd need to invert the Data.Either -> Data.String import. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 20:37:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 20:37:33 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.90a73d9c38b345119a248a07a0159d82@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | 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:D2709 Wiki Page: | Phab:D2720 Phab:D2930 -------------------------------------+------------------------------------- Comment (by Facundo Domínguez ): In [changeset:"13a85211040f67977d2a2371f4087d1d2ebf4de4/ghc" 13a85211/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13a85211040f67977d2a2371f4087d1d2ebf4de4" Desugar static forms to makeStatic calls. Summary: Using makeStatic instead of applications of the StaticPtr data constructor makes possible linting core when unboxing strict fields. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari, hvr Reviewed By: simonpj Subscribers: RyanGlScott, mboes, thomie Differential Revision: https://phabricator.haskell.org/D2930 GHC Trac Issues: #12622 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 13 20:53:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jan 2017 20:53:52 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns In-Reply-To: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> References: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> Message-ID: <071.4a38c46175b0b32aa06d61f67722b4b8@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | OverloadedLabels, | OverloadedStrings, OverloadedLists Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11671 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: OverloadedLabels OverloadedStrings OverloadedLists => OverloadedLabels, OverloadedStrings, OverloadedLists * related: 11671 => #11671 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 00:20:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 00:20: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.bf4ba6e76a6bbb098b34612cc93011a3@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've bisected some more. It looks almost certain that the change causing this problem was 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060, "Improve typechecking of instance defaults", whose commit message mentions that it slows down a test that involves a very large number of instance declarations. That message claims that real programs don't have nearly so many, but perhaps `store` proves that wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 00:30:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 00:30:32 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.b0cd571627e02aa9aec3bcb40660744d@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez 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:D2709 Wiki Page: | Phab:D2720 Phab:D2930 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 00:45:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 00:45:33 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.2f368964e3d4cc8be1497b5874d8f3e2@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: | -------------------------------------+------------------------------------- Comment (by simonpj): Quadrupling memory, adding 4Gb (that's a LOT of memory), is ridiculous! Yes, there are a dozen or two instance declarations, but only some use the default methods, and even if they do typechecking them should not take tons of memory. Something is mysterious here. I'd try `-dshow-passes` before and after, to see if the code size changes. It shouldn't change as a result of the patch, but with numbers as above I bet it does! Then it'd be a question of seeing why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 00:52:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 00:52:34 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.479dd620502e4adb80ba7d167f42a7cb@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): It's also conceivable (but unlikely) that I identified the wrong commit. I will verify. The module uses an awful lot of TH. Could it be generating lots of instance declarations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 03:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 03:08:43 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly Message-ID: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- If we have {{{#!hs data V a deriving (Functor) }}} and we evaluate {{{#!hs f <$> (error "Boo!" :: Void) }}} we should really get a "Boo" error, rather than a useless "Void fmap" one. The offending code is in `compiler/typecheck/TcGenFunctor.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 05:06:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 05:06:01 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.f6605fc56bbec5940cc80ffb9e5d53ca@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I've made some progress on this, but I'm once again stuck. I'm using `tcUnifyTy` once again to check if two type signatures coincide according to the criteria listed above. But there's a case it doesn't catch: {{{#!hs class Foo a where bar :: forall b. a -> b default bar :: a -> Int bar = ... }}} Here, `tcUnifyTy` happily unifies `b` with `Int`, yielding a false positive. So I need to find some way to prevent `b` from unifying with concrete types like `Int`. (Does skolemizing it accomplish this?) But we'd also want this to be accepted: {{{#!hs class Foo a where bar :: forall b. a -> b default bar :: forall c. a -> c bar = ... }}} Since `a -> c` is just a simple alpha-renaming of `a -> b`. So how can we tell `b` to unify with `c` but not with `Int`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 05:24:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 05:24:28 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.6bbc577b837ab4457c49687fb45e2ca3@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, there's certainly a technical issue in that quoting //any// function (not just pattern synonyms) will always add explicit quantification if it isn't present to begin with. For example: {{{ λ> putStrLn $([d| id :: a -> a; id x = x |] >>= stringE . pprint) id_0 :: forall a_1 . a_1 -> a_1 id_0 x_2 = x_2 λ> putStrLn $([d| id :: a -> a; id x = x |] >>= stringE . show) [SigD id_6989586621679026833 (ForallT [PlainTV a_6989586621679026832] [] (AppT (AppT ArrowT (VarT a_6989586621679026832)) (VarT a_6989586621679026832))),FunD id_6989586621679026833 [Clause [VarP x_6989586621679026834] (NormalB (VarE x_6989586621679026834)) []]] }}} Note how the `ForallT [PlainTV a_6989586621679026832] ...` gets added. So we'd need to be able to somehow preserve the fact that `id` was originally quoted without explicit quantification. We'd need to do this for functions and pattern synonyms for sure (and maybe other declarations that I'm not thinking of right now?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 06:19:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 06:19:49 -0000 Subject: [GHC] #13118: let binding tuple of lenses error not an expression Message-ID: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> #13118: let binding tuple of lenses error not an expression -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- This error seems to be fixed in GHC Head +/- 10 commits, but exists in GHC 8.0.1. I was told it might be a useful test case. {{{ λ> :t userId userId :: (RElem UserId rs (RIndex UserId rs), Functor f) => (Int -> f Int) -> Record rs -> f (Record rs) λ> let recLenses = userId &: Nil λ> :t recLenses recLenses :: (Functor f, RElem UserId rs (RIndex UserId rs)) => Record '[s :-> ((Int -> f Int) -> Record rs -> f (Record rs))] λ> :t recUncons recUncons :: Record (s :-> a : rs) -> (a, Record rs) λ> :t recUncons recLenses recUncons recLenses :: (Functor f, RElem UserId rs (RIndex UserId rs)) => ((Int -> f Int) -> Record rs -> f (Record rs), Record '[]) λ> let (l, ls) = recUncons recLenses : error: not an expression: ‘let (l, ls) = recUncons recLenses’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 06:51:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 06:51:55 -0000 Subject: [GHC] #13119: yesod-auth-1.4.15: ghc: panic! (the 'impossible' happened) Linker error Message-ID: <046.c9301e7c91710c08ea06cbe6838b0d57@haskell.org> #13119: yesod-auth-1.4.15: ghc: panic! (the 'impossible' happened) Linker error ---------------------------------+--------------------------------- Reporter: mcmayer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: ghc panic | Operating System: MacOS X Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- On Mac OS X 10.12.2 the [http://brew.sh] installation of Haskell `stack` is used (`brew install haskell-stack`). Next, the `yesod-simple` template is instantiated and built, e.g. {{{ stack new my-web yesod-simple cd my-web stack build }}} The error looks like this: {{{ ➜ my-web stack build yesod-auth-1.4.15: configure yesod-auth-1.4.15: build Progress: 1/4 -- While building package yesod-auth-1.4.15 using: /Users/mmayer/.stack/setup-exe-cache/x86_64-osx/Cabal- simple_mPHDZzAJ_1.22.5.0_ghc-7.10.3 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /private/tmp/my-web/.stack-work/logs/yesod- auth-1.4.15.log Configuring yesod-auth-1.4.15... Building yesod-auth-1.4.15... Preprocessing library yesod-auth-1.4.15... [ 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/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/stack44665 /yesod-auth-1.4.15/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/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/stack44665 /yesod-auth-1.4.15/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/stack44665 /yesod-auth-1.4.15/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/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/stack44665 /yesod-auth-1.4.15/Yesod/Auth/Message.hs:24:1: Warning: The import of ‘mappend’ from module ‘Data.Monoid’ is redundant /private/var/folders/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/stack44665 /yesod-auth-1.4.15/Yesod/Auth/Message.hs:460:1: Warning: Pattern match(es) are overlapped In an equation for ‘finnishMessage’: finnishMessage Password = ... /private/var/folders/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/stack44665 /yesod-auth-1.4.15/Yesod/Auth/Message.hs:460: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/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/ghc44706_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/mj/9fhlhndj3jl8mrd9czmhvz_00000gn/T/ghc44706_0/libghc_21.dylib: malformed mach-o: load commands size (35848) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The same happens on `ghc-8.0.1` (`stack build yesod-auth`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 11:08:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 11:08:57 -0000 Subject: [GHC] #12766: Allow runtime-representation polymorphic data families In-Reply-To: <051.3d7f378b0f8aa6ff42ef4e0c3f30e9dd@haskell.org> References: <051.3d7f378b0f8aa6ff42ef4e0c3f30e9dd@haskell.org> Message-ID: <066.cf08c2272323fb7d416a5f43e3ebd081@haskell.org> #12766: Allow runtime-representation polymorphic data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Explore how ticket:12369#comment:3, ticket:12369#comment:4 fit into this. TODO How `Free` fits with [https://github.com/ghc-proposals/ghc- proposals/pull/30 Levity-Polymorphic Type Classes], can we define **something** like this {{{#!hs newtype instance Free (k :: TYPE rep -> Constraint) -> (TYPE rep -> TYPE rep) where Free0 :: (forall q. k q => (p -> q) -> q) -> Free k p }}} TODO or like this {{{#!hs newtype instance Fix (f :: TYPE rep -> TYPE rep) :: TYPE rep where In :: f (Fix f) -> Fix f }}} And would they be useful -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 11:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 11:19:16 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns In-Reply-To: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> References: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> Message-ID: <071.01ff85d79d432c62d838822e3aa141f8@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | OverloadedLabels, | OverloadedStrings, OverloadedLists Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11671 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 13:04:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 13:04:23 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.5d9ac782b8bbbbb3a5e43093c145c478@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The substitution of `x` for `y` in the note you mention above sounds rather wrong for pointer equality. In particular, we probably never want a pointer equality test to float out of a case on one of its arguments. Floating one *in* should be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 13:13:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 13:13:14 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.a7f38efb7ba35af7a0f45f3a0332229b@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Sorry; that last comment was unclear. If we have {{{#!hs case x of x' { _ -> case y of y' { _ -> case reallyUnsafePtrEquality# x' y' of {....}}} }}} and we substitute as above, {{{#!hs case x of x' { _ -> case y of y' { _ -> case reallyUnsafePtrEquality# x y of {....}}} }}} then wouldn't floating out lead to this? {{{#!hs let wrong = reallyUnsafePtrEquality# x y in { case x of x' { _ -> case y of y' { _ -> case wrong of { ... }}}} }}} Now the pointer equality test could be performed ''before'' the reductions that would make it much more precise! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 13:22:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 13:22:39 -0000 Subject: [GHC] #13120: Can't compile HEAD with ghc-7.10.1 Message-ID: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> #13120: Can't compile HEAD with ghc-7.10.1 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- (Yes, I'm still using `ghc-7.10.1` :) ) `compiler/util/Util.hs` exports `GHC.Stack.CallStack`, which is available since `7.10.2`. We can 1) drop older versions; 2) protect the export using `CPP`; 3) remove the export completely because it doesn't seem to be used anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 15:27:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 15:27:45 -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.ed6f7b1ef9b99272c731639e5fe918af@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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * related: => #13093 Comment: This works in my local tree with changes I haven't put up for review yet {{{ $ echo main | ../inplace/bin/ghc-stage2.exe --interactive -L/mingw64/lib -lcsfml-graphics ../SFML.hs GHCi, version 8.1.20170102: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ..\SFML.hs, interpreted ) Ok, modules loaded: Main. *Main> ---------------------- CircleShape 0x00000000062fa130 CircleShape 0x00000000062faa60 ---------------------- *Main> Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:00:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:00:04 -0000 Subject: [GHC] #13121: Investigate whether uploading build artifacts from harbormaster would be usful Message-ID: <049.7c32dc32e9d5ea84423377cf9fb4523c@haskell.org> #13121: Investigate whether uploading build artifacts from harbormaster would be usful -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In harbormaster it is possible to upload build artifacts and associate them with each build, for example we could upload the user manual for each build or even binaries. I am not sure what would be useful. One use case might be checking the rendering of the user guide when it is modified. The idea is to write a small utility program which uploads suitable artifacts and then add an extra build step to the relevant build plans which calls this program. The utility doesn't have to be in-tree as it can be installed in the environment. Some more information: * There are some bindings to the phabricator API in [https://github.com /haskell-infra/arc-lite arc-lite] * The relevant API methods are `file.allocate`, `file.upload` and `harbormaster.createartifact` * `file.allocate` allows you to specify a time to delete a file, this would be good to avoid consuming lots of storage for builds. * Artifacts appear in the "artifacts" tab [https://phabricator.haskell.org/harbormaster/build/18367/ here] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:12:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:12:38 -0000 Subject: [GHC] #10073: Idris REPL is pretty and we can too In-Reply-To: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> References: <048.41fb030b4d1813ef94f8c7de6a966874@haskell.org> Message-ID: <063.1a39f09daf06e2a38c920f7f95977e75@haskell.org> #10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8809,#10179 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: Rufflewind (added) * status: new => closed * resolution: => fixed Comment: The error messages are now colourful to some degree. I will close this ticket unless there is a precise suggestion you have in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:15:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:15:44 -0000 Subject: [GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage Message-ID: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> #13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: -------------------------------------+------------------------------------- The phabricator API provides a method `harbormaster.sendmessage` which allows builds to report information back so that it is displayed on the interface. The goal is to avoid having to delve into the build logs in order to investigate failures. Information about the API method can be found in [https://phabricator.haskell.org/conduit/method/harbormaster.sendmessage/ conduit]. The API provides a rich set of options to report different information about a build. Some ideas: * Reporting the precise location of all terminal build errors * Reporting the outcome of all tests (this might be quite noisy but the only way to see is to try!) I don't know whether this is a good idea or how it works precisely but integrating harbourmaster with differential would be an efficiency gain. This is potentially related to #8809. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:29:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:29:10 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't Message-ID: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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 discovered this when debugging #13018. This code: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} module Bug where $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a idProxy x = x |]) }}} Used to compile on GHC 7.10.3: {{{ $ /opt/ghc/7.10.3/bin/ghci -ddump-splices Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(8,5): Splicing declarations [d| idProxy_avY :: forall proxy_aw0 (a_aw1 :: k_avZ). proxy_aw0 a_aw1 -> proxy_aw0 a_aw1 idProxy_avY x_aw2 = x_aw2 |] ======> idProxy_a3yP :: forall proxy_a3yN (a_a3yO :: k_avZ). proxy_a3yN a_a3yO -> proxy_a3yN a_a3yO idProxy_a3yP x_a3yQ = x_a3yQ Ok, modules loaded: Bug. }}} But on GHC 8.0.2 and HEAD, it's spuriously rejected: {{{ $ /opt/ghc/8.0.2/bin/ghci -ddump-splices Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(8,5): Splicing declarations [d| idProxy_a13B :: forall proxy_a13D (a_a13E :: k_a13C). proxy_a13D a_a13E -> proxy_a13D a_a13E idProxy_a13B x_a13F = x_a13F |] ======> idProxy_a3LN :: forall k_a3LK proxy_a3LL (a_a3LM :: k_a3LK). proxy_a3LL a_a3LM -> proxy_a3LL a_a3LM idProxy_a3LN x_a3LO = x_a3LO Bug.hs:6:3: error: Type variable ‘k_a3LK’ used in a kind. Did you mean to use TypeInType? the type signature for ‘idProxy_a3LN’ }}} Notice that in GHC 8.0.2, it's explicitly quantifying the `k`! This shouldn't happen, since in the source declaration it was implicit. The culprit is [http://git.haskell.org/ghc.git/blob/13a85211040f67977d2a2371f4087d1d2ebf4de4:/compiler/deSugar/DsMeta.hs#l735 rep_wc_ty_sig]. It is always explicitly quantifying all type variables, both explicit and implicit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:30:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:30:49 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.bddde10b0648c309a16b4fa26307ba2d@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): See also #13118, where a overeager quantification causes a different error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:32:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:32:17 -0000 Subject: [GHC] #13118: let binding tuple of lenses error not an expression In-Reply-To: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> References: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> Message-ID: <062.fb29fa3037c34fdd9e9050998de5e882@haskell.org> #13118: let binding tuple of lenses error not an expression -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Maybe. But what is `userId`? `Nil`? `recUncons`? Without the source of the program you're using, we can't reproduce this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 18:49:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 18:49:39 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.7a0f6fdd62117bb92024126328daf3ea@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: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm a bit confused about the status of this ticket. The original poster suggests adding carets to error messages, this has now been done but the discussion in the ticket has moved all over the place. I want to bring order to the chaos! I think a new ticket which focuses just on the issue of adding semantic information to error messages should be created. There should also be (dare I say it...) a wikipage which outlines the suggested designs on this ticket. Richard, great that your student wants to work on this. Is that still the plan? Could she perhaps take care of creating the new ticket and the wikipage if she decides to take ownership of this. I entered this ticket with the intention to do so but don't want to step on her toes. When I last looked at this it seemed that the main problem was #10735 which talks about the problems with `pretty` which have so far put everyone off working on this (me included). The crux of the matter is that `pretty` isn't very efficient and we use it in the code generator. The solution here seems to be to use a different (simpler) pretty printing library for code generation as this shouldn't require complicated layout instructions such as hanging or nesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 19:03:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 19:03:06 -0000 Subject: [GHC] #13118: let binding tuple of lenses error not an expression In-Reply-To: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> References: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> Message-ID: <062.fa51438ee3f52ae00299596b58c4716e@haskell.org> #13118: let binding tuple of lenses error not an expression -------------------------------------+------------------------------------- Reporter: codygman | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | 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): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 20:04:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 20:04:59 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.3569c698d98198db11995181c7758860@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2974 Comment: Phab:D2974 should fix this. If folks like this approach, I'll adapt it to fix #13018. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 21:25:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 21:25:12 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.c3035b70fe0c4159823679b682006dd2@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: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): mpickering, I agree that the issue of semantics messages should be moved to another ticket. Richard, perhaps you could have your student do this when the semester starts up? > The solution here seems to be to use a different (simpler) pretty printing library for code generation as this shouldn't require complicated layout instructions such as hanging or nesting. As I've expressed in the past, I'm not at all sure that the solution to #10735 is to invent another pretty-printer. As far as I know there is no reason why the semantics implemented by `pretty` can't be implemented with the exact same computation effort as a simpler printer in the case of infinite ribbon width. I know that I have found the ability to spit out `SDoc`s in assembler output to be quite useful in the past and I would hate to lose it, especially if doing so meant introducing a redundant pretty-printing implementation which could be avoided with a bit of refactoring. Of course, if I'm wrong and there is a fundamental reason why `pretty` incurs an unavoidable overhead then I'm happy to concede this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 21:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 21:36:19 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.944dca9cd5488154790e2dec187cbb9e@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2974 * milestone: => 8.2.1 Comment: Happily, having quoting respect implicitly quantified variables turned out to be simple. Phab:D2974 fixes this without needing to implement any splitting rule sorcery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 21:36:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 21:36:32 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.861b23709726d9359df848c45a87617b@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 22:36:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 22:36:26 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.9b9d141e0ce150e8194a91125cf0f76b@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: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, it is still the plan for my student to work on this. But I would not expect much progress soon, as this student is still in the process of learning Haskell. She and I will meet next week to frame our work for the semester, but I doubt she'll be ready to knowledgeably make a wiki page, etc., until Feb at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:21:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:21:45 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.4284093bb67ac9092f2baf88b028b087@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: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:48 bgamari]: > mpickering, I agree that the issue of semantics messages should be moved to another ticket. Richard, perhaps you could have your student do this when the semester starts up? > > > The solution here seems to be to use a different (simpler) pretty printing library for code generation as this shouldn't require complicated layout instructions such as hanging or nesting. > > As I've expressed in the past, I'm not at all sure that the solution to #10735 is to invent another pretty-printer. As far as I know there is no reason why the semantics implemented by `pretty` can't be implemented with the exact same computation effort as a simpler printer in the case of infinite ribbon width. I know that I have found the ability to spit out `SDoc`s in assembler output to be quite useful in the past and I would hate to lose it, especially if doing so meant introducing a redundant pretty-printing implementation which could be avoided with a bit of refactoring. > > Of course, if I'm wrong and there is a fundamental reason why `pretty` incurs an unavoidable overhead then I'm happy to concede this point. To put this in context, no one is still sure where the problem in `pretty` lies and this isn't for lack of trying. At least @thomie, @erikd and @niteria (three very fine hackers) have tried to find out where the problems are but haven't managed to find a fix. We don't want to move ahead with this until #10735 is resolved as doing so would cause `pretty` to diverge even further. This being said, I consider this ticket a high priority for 8.4 as it finally will provide better support for tooling. This is why I don't want it to be blocked on a very difficult ticket when there is a simple albeit suboptimal solution on the table. The benefit of implementing this outweighs the cost of the loss of convenience in the code generation in my opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:22:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:22:27 -0000 Subject: [GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals Message-ID: <045.3b1e3cade00998df210490cd104467e8@haskell.org> #13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, TH expressions and patterns store Float/Double values as rationals: http://hackage.haskell.org/package/template- haskell-2.11.1.0/docs/Language-Haskell-TH-Syntax.html#t:Lit Unfortunately, this isn't sufficient, as there is no way to properly support usual floating point values such as NaN, Infinity, and Negative- Zero. This is true for both expressions and patterns. It would be nice if Double/Float literals were stored as double-floats themselves, instead of rationals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:30:41 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs Message-ID: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: panic, GADTs | Operating System: MacOS X 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 encoding of Russel's paradox using GADTs causes GHC to panic, which is understandable as it involves creating a value of an uninhabited data type without using any recursion, which should not be possible as far as I can tell, so this should probably not type check. {{{#!hs {-# LANGUAGE GADTs #-} data False data R a where MkR :: (c (c ()) -> False) -> R (c ()) condFalse :: R (R ()) -> False condFalse x@(MkR f) = f x absurd :: False absurd = condFalse (MkR condFalse) main :: IO () main = absurd `seq` print () }}} When compiled with optimization I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone condFalse To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6441 }}} When I instead load it into GHCi and type "absurd `seq` ()" I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): atomPrimRep case absurd of _ [Occ=Dead] { } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:32:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:32:40 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.c0673e253aa43171c3443c0426cb105f@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: panic, GADTs Operating System: MacOS X | 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 tysonzero: @@ -37,1 +37,1 @@ - When I instead load it into GHCi and type "absurd `seq` ()" I get: + When I instead load it into GHCi and type "{{{absurd `seq` ()}}}" I get: New description: The following encoding of Russel's paradox using GADTs causes GHC to panic, which is understandable as it involves creating a value of an uninhabited data type without using any recursion, which should not be possible as far as I can tell, so this should probably not type check. {{{#!hs {-# LANGUAGE GADTs #-} data False data R a where MkR :: (c (c ()) -> False) -> R (c ()) condFalse :: R (R ()) -> False condFalse x@(MkR f) = f x absurd :: False absurd = condFalse (MkR condFalse) main :: IO () main = absurd `seq` print () }}} When compiled with optimization I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone condFalse To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6441 }}} When I instead load it into GHCi and type "{{{absurd `seq` ()}}}" I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): atomPrimRep case absurd of _ [Occ=Dead] { } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:37:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:37:16 -0000 Subject: [GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage In-Reply-To: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> References: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> Message-ID: <064.cd98fcc64e0d3e1cc37cdf2f5a61d246@haskell.org> #13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The results look quite nice rendered on the upstream installation. https://secure.phabricator.com/B15264 I think it is easy to implement reporting the outcome of the testsuite in this way but reporting compiler errors is almost certainly blocked by #8809. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:37:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:37:32 -0000 Subject: [GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage In-Reply-To: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> References: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> Message-ID: <064.d54b26e2c3d633bfcdd039deaf441347@haskell.org> #13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8809 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * blockedby: => 8809 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:44:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:44:26 -0000 Subject: [GHC] #13126: Support for hexadecimal floats Message-ID: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> #13126: Support for hexadecimal floats -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Currently, Haskell only allows writing floating-point numbers in the decimal format. Unfortunately, writing floats in decimal/scientific format is not always the best option, due to loss of precision. As an alternative, there's the so called "hexadecimal floating point" format, described in p57-58 of: http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1256.pdf The format is rather simple, unambiguous, and relatively easy to implement. And it's been around for about 10 years by now. It would be nice if the Haskell standard was changed to include such literals. But in the meantime, perhaps GHC can support such literals via a pragma, such as `LANGUAGE HexadecimalFloats` or similar. A corresponding pretty printer (similar to C's %a specifier) is also needed; which should go into the standard `Numerics` module. Such a function can be called `showHFloat` to accompany the similarly named functions for rendering float values. A reference implementation can be given by template-Haskell splicing, and indeed the hackage package FloatingHex (http://hackage.haskell.org/package/FloatingHex) provides both a quasi- quoter for such literals, and the pretty printer `showHFloat.` Unfortunately, this solution is less than satisfactory as it relies on the rather heavy mechanism for quasi-quotes, requires an extra library dependency, a pragma (`QuasiQuotes`), and the import and dependency of a hackage package, which sounds a lot for just being able to write floats precisely! Furthermore, Tempate Haskell has an issue with the storage of floats (https://ghc.haskell.org/trac/ghc/ticket/13124), which makes the library solution less than ideal in overflow cases. (Long story short: Template- Haskell stores floating literals as rationals, and thus has no reliable way of representing floats such as NaN, Infinity, and especially negative- zero.) Numeric programming is important, especially in this new era of HPC, and many-core architectures tuned for crunching floating-point data seamlessly. While this is admittedly a minor step, I think it'll be a positive addition to GHC from a maturity perspective, and that of matching/leading other languages out there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:50:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:50:04 -0000 Subject: [GHC] #13128: Refactor AvailInfo to be more sensible Message-ID: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> #13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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: -------------------------------------+------------------------------------- `AvailInfo` has been the bane of my life for the last 12 months and I want to tame it. There are two main problems with it. 1. There is this horrible invariant where if the parent is also exported then it is the first element of the list of children. 2. The set of children and field labels are represented as lists which means many expensive calls to functions from `ListSetOps`. 1 Is easy enough to solve by adding a flag which says whether the parent is exported or not. My naive attempt to solve the second problem was to replace the list by a `NameSet`. At the interface file boundary, the `NameSet` is converted into a list using `nameSetElemsStable` to maintain determinism and only pay the cost of using this expensive function once. This ran into problems in `RnModIface` where there are several functions which map over the list of children. NameSets don't support mapping and so this is difficult to implement in a satisfactory way. The next plan of attack is to distinguish between `IfaceAvailInfo` and `AvailInfo`. The former will use the old representation (lists) in order to maintain determinism but the latter will use sets. Distinguishing the two modes is useful conceptually and practically. The data type is used in quite a few different ways in lots of places which makes writing a nice interface hard. This ticket is to record my trail in case I don't make it to the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:51:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:51:11 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.dd41c42e4e03ad9bcaaf678b561832ec@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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 carter): * status: new => closed * resolution: => duplicate Comment: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html #bugs-in-ghc see the remark at the end {{{ GHC’s inliner can be persuaded into non-termination using the standard way to encode recursion via a data type: data U = MkU (U -> Bool) russel :: U -> Bool russel u@(MkU p) = not $ p u x :: Bool x = russel (MkU russel) The non-termination is reported like this: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone x_alB To increase the limit, use -fsimpl-tick-factor=N (default 100) with the panic being reported no matter how high a -fsimpl-tick-factor you supply. We have never found another class of programs, other than this contrived one, that makes GHC diverge, and fixing the problem would impose an extra overhead on every compilation. So the bug remains un-fixed. There is more background in Secrets of the GHC inliner. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:53:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:53:01 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.836f983af28a0b19a1271c2047b88510@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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 first panic is certainly a duplicate of this. I'm not sure the second panic is duplicate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:56:59 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.9b32dd08304aa83535e416c97bd2126b@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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): Perhaps #12128? I could reproduce this on 8.0.1 but with HEAD it just loops forever. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 14 23:58:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jan 2017 23:58:46 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.b5d33af5b90e04f751d35d28a8c8ad47@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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 tysonzero: @@ -2,3 +2,1 @@ - panic, which is understandable as it involves creating a value of an - uninhabited data type without using any recursion, which should not be - possible as far as I can tell, so this should probably not type check. + panic. @@ -24,1 +22,1 @@ - When compiled with optimization I get: + When compiled with optimizations I get: New description: The following encoding of Russel's paradox using GADTs causes GHC to panic. {{{#!hs {-# LANGUAGE GADTs #-} data False data R a where MkR :: (c (c ()) -> False) -> R (c ()) condFalse :: R (R ()) -> False condFalse x@(MkR f) = f x absurd :: False absurd = condFalse (MkR condFalse) main :: IO () main = absurd `seq` print () }}} When compiled with optimizations I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone condFalse To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6441 }}} When I instead load it into GHCi and type "{{{absurd `seq` ()}}}" I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): atomPrimRep case absurd of _ [Occ=Dead] { } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 00:27:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 00:27:20 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.fa3d8e3b03280e5fcdae1d9e626e0d07@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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 carter): @mpickering perhaps the ghci panic is valid because this type gives a weak form of unsafe coerce? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 01:31:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 01:31:22 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.8207b51ab22ee7211eb9c884ef8711d1@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: | -------------------------------------+------------------------------------- Comment (by Rufflewind): TBH, I think `SDoc` is too low level to embed rich semantic information like expressions, locations etc. It should stick to what it does best: laying out dumb text data. Instead, I think it'd be nicer to have a simple high-level data type for diagnostics, which could look like: {{{#!hs data Error = Error Severity (Maybe ErrorID) ErrorMessage [(Location, Maybe Expression)] type ErrorID = String -- i.e. flag that disables the warning -- it'd be nice to have them for errors too type ErrorMessage = [ErrMsgSegment] data ErrMsgSegment = EDoc SDoc | ELink Int -- link to some expression of interest }}} … something along those lines. There's plenty of room to bikeshed on the details, but it'd be great to keep it as simple as possible so as to minimize the effort required by downstream to interpret the diagnostics. In contrast, an `SDoc` does not give the consumer a lot of flexibility in the display of an error. This approach allows for a gradual transition: simply edit the legacy error-emitting framework to emit an `Error severity Nothing (EDoc msg) [(loc, Nothing)]`, which is the kind of “dumb” error that we have today. To take advantage of the new system, we just bypass the legacy framework and create `Error`s directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 01:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 01:37:02 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.ced9c91b08c8ef0559da99954c05752c@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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 tysonzero): Should the issue be re-opened until we are sure that the second panic is either a duplicate or resolved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 01:44:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 01:44:51 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.187913e90410194c1b7c81b0d99b121e@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: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm a little lost now. It looks like `pretty` already has the annotations proposed in comment:3. So is #10735 really all that's left to allow annotations within `SDoc`s? And I remember somewhere that color would be impossible without a design like comment:3... and yet we have color now. Re comment:52: I like this idea a good deal, and I'll admit it's where I started my thinking about this problem, but then comment:3 seemed to go in a different (but quite worthwhile) direction. So I guess the direct question is: what should my student and I work on? Adding annotations to `SDoc`s seems redundant. Tackling #10735 will likely be beyond her level of experience. So I'm tempted to steer her toward comment:52... but I'd love some feedback before we start getting in too deep in one particular direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 08:35:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 08:35:38 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.5929df3036ee42746016a1bacdfc1537@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: | -------------------------------------+------------------------------------- Comment (by mpickering): Phil makes a good point about where the semantic information should be embedded. In fact, this semantic information is already there in two cases, which flag the warning was caused by and the position of the error (see `TcRnMonad.add_warn_at`). In fact, looking at `ErrMsg`, there is already a lot of semantic information present there as well. These errors are then caught by `ioMsgMaybe` in `HscMain` and reported by `throwErrors` where the information is somehow lost but I have to go! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 08:44:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 08:44:49 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.0686e4417f71acc272f22478e6958925@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: | -------------------------------------+------------------------------------- Comment (by mpickering): It seems that the `Show` instance for `ErrMsg` needs to be investigated as well as functions like `throwOneError` which bypass all this machinery. This is starting to seem infinitely more tractable now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 12:02:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 12:02:16 -0000 Subject: [GHC] #13120: Can't compile HEAD with ghc-7.10.1 In-Reply-To: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> References: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> Message-ID: <059.45c157efceb5a228549631015f56267d@haskell.org> #13120: Can't compile HEAD with ghc-7.10.1 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 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): Phab:D2976 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: => Yuras * differential: => Phab:D2976 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 12:07:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 12:07:44 -0000 Subject: [GHC] #13129: Warn about home module, not listed in commang line Message-ID: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> #13129: Warn about home module, not listed in commang line -------------------------------------+------------------------------------- Reporter: Yuras | 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: -------------------------------------+------------------------------------- It is an attempt to fix this cabal issue: https://github.com/haskell/cabal/pull/1455 Basically, when user fails to list all modules in `exposed-modules` or `other-modules`, cabal produces broken package. The idea of the fix is to teach GHC to warn about home modules (not from an other package), that are not explicitly listed in command line. Option name `-Wmissing-home-modules` is a subject for bikeshedding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 12:39:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 12:39:43 -0000 Subject: [GHC] #13129: Warn about home module, not listed in commang line In-Reply-To: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> References: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> Message-ID: <059.5ef17d68dc7a96482beb1cfaa22dc5e7@haskell.org> #13129: Warn about home module, not listed in commang line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => phab:D2977 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 13:00:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 13:00:21 -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.fc1a4be5042c210d2c889e485b0b6683@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 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 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"f63c8ef33ec9666688163abe4ccf2d6c0428a7e7/ghc" f63c8ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f63c8ef33ec9666688163abe4ccf2d6c0428a7e7" Use latin1 code page on Windows for response files. Summary: D2917 added a change that will make paths on Windows response files use DOS 8.3 shortnames to get around the fact that `libiberty` assumes a one byte per character encoding. This is actually not the problem, the actual problem is that GCC on Windows doesn't seem to support Unicode at all. This comes down to how unicode characters are handled between POSIX and Windows. On Windows, Unicode is only supported using a multibyte character encoding such as `wchar_t` with calls to the appropriate wide version of APIs (name post-fixed with the `W` character). On Posix I believe the standard `char` is used and based on the value it is decoded to the correct string. GCC doesn't seem to make calls to the Wide version of the Windows APIs, and even if it did, it's character representation would be wrong. So I believe GCC just does not support utf-8 paths on Windows. So the hack in D2917 is the only way to get Unicode support. The problem is however that `GCC` is not the only tool with this issue and we don't use response files for every invocation of the tools. Most of the tools probably don't support it. Furthermore, DOS 8.1 shortnames only exist when the path or file physically exists on disk. We pass lots of paths to GCC that don't exist yet, like the output file. D2917 works around this by splitting the path from the file and try shortening that. But this may not always work. In short, even if we do Unicode correctly (which we don't atm, the GCC driver we build uses `char` instead of `wchar_t`) we won't be able to compile using unicode paths that need to be passed to `GCC`. So not sure about the point of D2917. What we can do is support the most common non-ascii characters by writing the response files out using the `latin1` code page. Test Plan: compile + make test TEST=T12971 Reviewers: austin, bgamari, erikd Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2942 GHC Trac Issues: #12971 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 13:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 13:02:35 -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.805a546d3b84ce284c59ca25e9868090@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 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-): * priority: highest => normal * status: patch => upstream Comment: This is as fixed as it's going to get with the current toolchain. We'll have to revisit this if we ever move toolchains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 13:07:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 13:07:57 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal In-Reply-To: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> References: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> Message-ID: <065.211539803bcddd085dcdfae7db9ad43a@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: T13082_good, | T13082_fail Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2941 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"331f88d0d878eae926b3c1c61a3ff344916b62ed/ghc" 331f88d0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="331f88d0d878eae926b3c1c61a3ff344916b62ed" Fix abort and import lib search on Windows Summary: Apparently `sysErrorBelch` doesn't terminate the program anymore making previously unreachable code now execute. If a dll is not found the error message we return needs to be a heap value. Secondly also allow the pattern `lib` to be allowed for finding an import library with the name `lib.dll.a`. Test Plan: ./validate, new tests T13082_good and T13082_fail Reviewers: austin, RyanGlScott, hvr, erikd, simonmar, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2941 GHC Trac Issues: #13082 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:44:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:44:11 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.26bd31fa1af9db342f6a306dea2bbfed@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: | -------------------------------------+------------------------------------- Comment (by bgamari): Phil, I'm not sure I understand your `ELink` constructor. Is the `Int` here a stand-in for any old type, or is this really an `Int`? If the latter, what does it represent? Not to discourage discussion of other options, but I'd just like to remind everyone that Idris has set some very nice precedent for the semantics- details-in-pretty-printer approach. David Christiansen summarizes this nicely in his HIW 2015 talk, [[https://www.youtube.com/watch?v=m7BBCcIDXSg]]. I'd encourage anyone interested in this ticket to watch this talk. In general I worry that by framing the problem solely in terms of "error messages" as done in comment:52 we miss out on the richness that the Idris folks enjoy. What enables their nice presentation is the fact that the semantically rich objects and the pretty-printer documents are one and the same. This means that any time your error `ppr`s a type/expression/source span/etc. you automatically get a rich representation for free. This is something that I believe would be non-trivial to reproduce in the approach of comment:52. Recall that in GHC we typically build up error messages compositionally from a variety of often nested pieces; it seems to me that by distinguishing "error messages" from `SDoc` we give up the ability to do this (unless, of course, we refactor our error message building blocks in terms of `ErrMsg`, in which case why didn't we just use `SDoc` to begin with?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:52:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:52:29 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.114e5e10be1f00f498242b7a3659c859@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: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:53 goldfire]: > I'm a little lost now. It looks like `pretty` already has the annotations proposed in comment:3. So is #10735 really all that's left to allow annotations within `SDoc`s? That is pretty much right. > And I remember somewhere that color would be impossible without a design like comment:3... and yet we have color now. > Well this isn't quite true. Yes, we have color, but I think part of the initial suggestion was to make much greater use of color throughout the message. For instance, we might render the type `Int` in one color and `String` in another, or perhaps render all types in one color and all expressions in another. For this we need more rich semantic content within the message so we don't need to bury the details of error message styling deep inside the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:56:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:56:05 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.9b9b0716b709348961be25f404127303@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | 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: #12795 | Differential Rev(s): Phab:D2876, Wiki Page: | Phab:D2952 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"db91d17edfbe7deecb62bbb89c804249f9c4a4bd/ghc" db91d17e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db91d17edfbe7deecb62bbb89c804249f9c4a4bd" Properly introduce CTimer to System.Posix.Types Summary: In ffc2327070dbb664bdb407a804121eacb2a7c734, an attempt was made at adding a Haskell wrapper around the C `timer_t` type. Unfortunately, GHC's autoconf macros weren't sophisticated enough at the time to properly detect that `timer_t` is represented by a `void *` (i.e., a pointer) on most OSes. This is a second attempt at `CTimer`, this time using `AC_COMPILE_IFELSE` to detect if a type is a pointer type by compiling the following program: ``` type val; *val; ``` This also only derives a small subset of class instances for `CTimer` that are known to be compatible with `Ptr` using a new `OPAQUE_TYPE_WITH_CTYPE` macro. Test Plan: ./validate Reviewers: erikd, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2952 GHC Trac Issues: #12795, #12998 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:56:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:56:05 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.33bc53d5a42baa8221f1d9d2e2572a37@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | 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:D2664 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"db91d17edfbe7deecb62bbb89c804249f9c4a4bd/ghc" db91d17e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db91d17edfbe7deecb62bbb89c804249f9c4a4bd" Properly introduce CTimer to System.Posix.Types Summary: In ffc2327070dbb664bdb407a804121eacb2a7c734, an attempt was made at adding a Haskell wrapper around the C `timer_t` type. Unfortunately, GHC's autoconf macros weren't sophisticated enough at the time to properly detect that `timer_t` is represented by a `void *` (i.e., a pointer) on most OSes. This is a second attempt at `CTimer`, this time using `AC_COMPILE_IFELSE` to detect if a type is a pointer type by compiling the following program: ``` type val; *val; ``` This also only derives a small subset of class instances for `CTimer` that are known to be compatible with `Ptr` using a new `OPAQUE_TYPE_WITH_CTYPE` macro. Test Plan: ./validate Reviewers: erikd, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2952 GHC Trac Issues: #12795, #12998 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:56:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:56:05 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows In-Reply-To: <044.d631d36f93220766b68ac911126e9f93@haskell.org> References: <044.d631d36f93220766b68ac911126e9f93@haskell.org> Message-ID: <059.67f3219a29c46b017a009814d0808e3b@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2969 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"c13151e5ac774d38d7c5a807692851022c18fe6b/ghc" c13151e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c13151e5ac774d38d7c5a807692851022c18fe6b" Improve access violation reporting on Windows Summary: This patch is courtesy of @awson. Currently, whenever GHC catches a segfault on Windows, it simply reports the somewhat uninformative message `Segmentation fault/access violation in generated code`. This patch adds to the message the type of violation (read/write/dep) and location information, which should help debugging segfaults in the future. Fixes #13108. Test Plan: Build on Windows Reviewers: austin, erikd, bgamari, simonmar, Phyx Reviewed By: bgamari, Phyx Subscribers: awson, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2969 GHC Trac Issues: #13108 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:56:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:56:30 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.359540b129dc9b3b083573693524c392@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: | -------------------------------------+------------------------------------- Comment (by alanz): And if the semantically rich errors can be accessed via the GHC API it makes much better options available to tool developers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:57:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:57:35 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.61e84ee164189b8bb9175855b80a960b@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | 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: #12795 | Differential Rev(s): Phab:D2876, Wiki Page: | Phab:D2952 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Fixed for real this time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 16:58:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 16:58:09 -0000 Subject: [GHC] #13108: Improve poor Access Violation reporting on Windows In-Reply-To: <044.d631d36f93220766b68ac911126e9f93@haskell.org> References: <044.d631d36f93220766b68ac911126e9f93@haskell.org> Message-ID: <059.2a9f42db1384d501fa5c4c41dbaeeb27@haskell.org> #13108: Improve poor Access Violation reporting on Windows -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 17:22:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 17:22:08 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.77977c5c9b6de3beac1e2a09444eebdb@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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): I said the panic is a duplicate of #12128 and I verified it doesn't happen on HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 17:24:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 17:24:24 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.a58915afc86733d5e682a09a8643e69e@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: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is how I see this ticket. There are two suggestions: 1. Make it possible to output error messages as JSON (what I want and easy with current infrastructure). 2. Add more semantic information to error messages (ie attaching the actually expressions to SDocs, what Ben is mainly talking about, idris style). Ben in his last comment is saying that if 2. is implemented then 1. comes for free (I think). The main advantage of 2. is that you can build interfaces which use the additional localised information to provide different information to users, ie highlighting, hovers etc. This seems right to me but implementing 2. is a significant amount of work compared to 1. and I can't imagine the exact design off the top of my head. My essential point is that 1. should not be blocked by 2. Once 2. is implemented then 1. can be reimplemented in terms of 2. There seems to be suggestions of how to resolve the `pretty` issue but even after that there is still an extremely large amount of work to embed the right information in the SDoc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 18:08:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 18:08:33 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.c9a2870cacae85d8b8f121b28d618079@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: | -------------------------------------+------------------------------------- Comment (by bgamari): alanz, indeed much of the motivation for providing these annotations to begin with is to enable tooling like Idris'. mpickering, your assessment is pretty much dead on. I agree that we can and should move ahead with (1) independently from (2). `ErrMsg` already includes the information that we would need to do this; all that needs to be done is to ensure that we don't lose it and potentially add some output format for tooling consumers (e.g. JSON). However, I think we should refrain from trying to solve the weakened form of (2) that comment:52 tackles. This approach appears to introduce a lot of accidental complexity for what is easily accomplished using an existing annotated pretty-printing library. The only thing holding us back from moving ahead here is #10735. As far as I can tell, the problem in #10735 is that both the [[https://github.com/ekmett/wl-pprint-extras/issues/16|Wadler-Leijen]] and [[https://github.com/haskell/pretty/issues/32|Hughes]] pretty-printers can become quadratic in some cases. This hurts a great deal in the case of GHC, where we use the pretty-printer to emit massive quantities of code. Mpickering has advocated that we work around the issue by simply eliminating the use of the pretty-printer for code generation. I would prefer that we not do this if possible. Ultimately I believe that the root cause of the non-linearity is back-tracking due to the document exceeding the ribbon width. However, when we are producing code we configure `pretty` with an infinite ribbon width, meaning that it should never be necessary to backtrack. Unfortunately the `pretty` implementation doesn't take advantage of this fact. I argue that this should be fixed. The other related issue is the inability to make use of `FastString` with the upstream `pretty` since the `text` combinator has type `String -> Doc`. This is actually a very poor interface as `text` needs the length of the string, which is an O(n) operation. Really it should at least allow usage of a more efficient string representation. niteria and I discussed this a few months ago and agreed that this could be resolved by simply generalizing `text` over its string type with a typeclass providing an `unpack` and `length` function. goldfire, does any of the above sound like a reasonable task for your student? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 19:38:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 19:38:14 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs In-Reply-To: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> Message-ID: <059.8e3524637e559a4d43b4a022bdc491d8@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: alanz Type: feature request | Status: patch Priority: low | 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:D2958 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"1ff3c5882427d704538250e6fdadd6f48bb08989/ghc" 1ff3c58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ff3c5882427d704538250e6fdadd6f48bb08989" Add dump-parsed-ast flag and functionality Summary: This flag causes a dump of the ParsedSource as an AST in textual form, similar to the ghc-dump-tree on hackage. Test Plan: ./validate Reviewers: mpickering, bgamari, austin Reviewed By: mpickering Subscribers: nominolo, thomie Differential Revision: https://phabricator.haskell.org/D2958 GHC Trac Issues: #11140 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 19:53:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 19:53:19 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.3dfa51de241a0bbfb84d369b7f2d47f3@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: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Replying to [comment:56 bgamari]: > Phil, I'm not sure I understand your `ELink` constructor. Is the `Int` here a stand-in for any old type, or is this really an `Int`? If the latter, what does it represent? It's meant to be an index that points to the relevant item inside the `[(Location, Maybe Expression)]`. It's not a very good representation for links, but that was just a sketch of the general idea. > What enables their nice presentation is the fact that the semantically rich objects and the pretty-printer documents are one and the same. If my understanding of David Christiansen's talk is right, then I don't agree that conflating pretty-printer documents and semantically rich objects is a good idea, because you are throwing away structural information in the process while also committing to a specific representation of the error message. In effect, the burden is shifted towards the consumers, because they have sift through the `Doc` to find the parts the want (what if they want to rearrange pieces of the error message?). Moreover, if GHC decides to make a superficial change in how the errors are laid out, then it will impact downstream consumers. If I may draw upon an analogy, this is kind of like if a web API decided to, instead of emitting data using simple JSON, emitted full-blown HTML files that are many times more difficult to parse while also requiring you do sift through the HTML elements to find the parts you want. Meanwhile, you'd worry what would happen to the structure if the web API gets upgraded. I'm all for semantically rich error messages. `Error` data type I sketched earlier could be tweaked to allow for the kinds of things that David Christiansen talks about. But by keeping the structural information it would provide a more informative interface for consumers downstream. In other words, I would much prefer: {{{#!hs Error loc (TypeMismatch expr1 expr2) }}} than {{{#!hs docLoc loc <+> text "Type mismatch:" <+> docExpr expr1 <+> "vs" <+> docExpr expr2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 20:20:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 20:20:20 -0000 Subject: [GHC] #11789: Flag suggestion does not always work In-Reply-To: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> References: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> Message-ID: <061.8b7fe9571fed9a70d9b71d3d23b08389@haskell.org> #11789: Flag suggestion does not always work -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | 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: #11429 | Differential Rev(s): Phab:D2978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D2978 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 21:19:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 21:19:52 -0000 Subject: [GHC] #13130: atomicModifyMutVar# has incorrect type Message-ID: <045.780a635d79815aa0591355968d4537c8@haskell.org> #13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- this ticket specifically, currently we only expose in ghc-prim {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> b) -> State# s -> (# State# s,c #) }}} is the type more like the following? {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> (#a,b #)) -> State# s -> (# State# s,b #) }}} looking at GHC.IOREF {{{ atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b atomicModifyIORef (IORef (STRef r#)) f = IO $ \s -> atomicModifyMutVar# r# f s }}} it seems that either way, something screwy is afoot i'm not sure where the spurious c type variable comes from -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 21:23:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 21:23:14 -0000 Subject: [GHC] #13131: add effectful version of atomicModifyMutVar# Message-ID: <045.8cb013f9c57e3f0110e075839473d66a@haskell.org> #13131: add effectful version of atomicModifyMutVar# -------------------------------------+------------------------------------- Reporter: carter | 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: -------------------------------------+------------------------------------- something like {{{ atomicEffectfulModifyMutVar# :: MutVar# s a -> ((# a, State# s #) -> (# State# s , a , b#)) -> State# s -> (#State# s, b #) }}} this isn't quite safely expressible currently without some unsafeCoercion highjinks that I'm not sure are robust -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 22:10:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 22:10:55 -0000 Subject: [GHC] #13132: Compilation fails with a panic: get_op runContT Message-ID: <047.3dec28169f89b6cc38d752cf024ea4ab@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Compiling 'tersmu' from Hackage fails with the following: {{{ [13 of 16] Compiling ParseM ( ParseM.hs, ParseM.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): get_op runContT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code can be found [https://gitlab.com/zugz/tersmu here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 22:41:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 22:41:48 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.21538d3d98298702027a090022e8c6d0@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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 andreas.abel): What should the implementation of `fmap` be here? {{{#!hs fmap _ x = x `seq` error "Void fmap" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:02:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:02:08 -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.c9f3345d315dd37b206698a98d48884d@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Have you tried with 8.0.2? It might be #10618 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:05:35 -0000 Subject: [GHC] #13070: time after evaluation In-Reply-To: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> References: <044.7e534510fb6c79d684cd1e554f7962ee@haskell.org> Message-ID: <059.f051ea78c3fac24dc88f2793e29dbf5a@haskell.org> #13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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): * milestone: 8.0.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:17:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:17:52 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.60c085b8539d5f149870e987b88dff35@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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 dfeuer): My preference would be {{{#!hs fmap _ x = case x of }}} (effectively using `EmptyCase`). mpickering indicates there was some prior dispute about this, but I don't know where. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:24:14 -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.aadb434662d42ba764aa6df13e14a5f5@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I tried with 8.0.2 (`cabal install tersmu`) and the same panic exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:47:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:47:12 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.077c63a632036ad3895f0d249db4ba9b@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In light of Richard's suggestion on the Phab Diff, I've opened [https://github.com/ghc-proposals/ghc-proposals/pull/36 a GHC proposal] to discuss the specifics of introducing `ImplicitForallT` and `ImplicitForallC` to contain implicitly quantified type variables in quoted type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:47:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:47:20 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.6c73eb0e2e1cf62cf9f4cc0a058a43ed@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In light of Richard's suggestion on the Phab Diff, I've opened [https://github.com/ghc-proposals/ghc-proposals/pull/36 a GHC proposal] to discuss the specifics of introducing `ImplicitForallT` and `ImplicitForallC` to contain implicitly quantified type variables in quoted type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:51:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:51:43 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.ae176075090d34a7324272a64805191d@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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: #7401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #7401 Comment: The discussion is at #7401, which proposed an overhaul of the way derived instances for void types work. Ultimately, a consensus was never reached as to how derived `Eq` instances should work. See https://ghc.haskell.org/trac/ghc/ticket/7401#comment:46. If someone would be willing revive that discussion and advocate for a position, I'd be very appreciative, as I'm hesitant to poke that sleeping dragon again :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 15 23:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jan 2017 23:52:22 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.276308e1e3e655e2aca2b9ceb4b9898f@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10577, #13117 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:38:57 -0000 Subject: [GHC] #13125: GHC Panics when encoding Russel's paradox using GADTs In-Reply-To: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> References: <048.47f1262c981ff1a9a3c45abea7cc9f89@haskell.org> Message-ID: <063.25642e80c109febfa3ae764741715683@haskell.org> #13125: GHC Panics when encoding Russel's paradox using GADTs -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: panic, GADTs Operating System: MacOS X | 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 tysonzero): Ok great, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:42:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:42:21 -0000 Subject: [GHC] #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) Message-ID: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) -------------------------------------+------------------------------------- Reporter: jboydt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] hexEscape_a2tI :: t_a2tH[tau:1] (CHoleCan: hexEscape)} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:43:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:43:00 -0000 Subject: [GHC] #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) In-Reply-To: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> References: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> Message-ID: <060.d66e3ae9434af10d1aea916f22a49266@haskell.org> #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) -------------------------------------+------------------------------------- Reporter: jboydt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 jboydt): * Attachment "PrettyJSON.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:43:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:43:13 -0000 Subject: [GHC] #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) In-Reply-To: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> References: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> Message-ID: <060.28b88358b087a01795dc9af4cdcdcc65@haskell.org> #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) -------------------------------------+------------------------------------- Reporter: jboydt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 jboydt): * Attachment "SimpleJSON.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:43:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:43:24 -0000 Subject: [GHC] #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) In-Reply-To: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> References: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> Message-ID: <060.11383c735c71fb12b04d22cec1f3484a@haskell.org> #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) -------------------------------------+------------------------------------- Reporter: jboydt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 jboydt): * Attachment "PrettyStub.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:44:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:44:54 -0000 Subject: [GHC] #13134: Simplifier ticks exhausted Message-ID: <047.364cf07e914f812155e6ad25772ad938@haskell.org> #13134: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When compiling generics-rich code I got this panic. I had to increase `-fsimpl-tick-factor` to 110 to fix the problem. {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone f_s1dfn To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 19189 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I attached the output of `-ddump-simpl-stats`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 00:45:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 00:45:59 -0000 Subject: [GHC] #13134: Simplifier ticks exhausted In-Reply-To: <047.364cf07e914f812155e6ad25772ad938@haskell.org> References: <047.364cf07e914f812155e6ad25772ad938@haskell.org> Message-ID: <062.a821f936caa914b26ee12151561d5cbc@haskell.org> #13134: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: task | Status: new Priority: low | 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: | -------------------------------------+------------------------------------- Changes (by fumieval): * Attachment "ddump-simpl-stats" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 01:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 01:13:25 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.34f3056187c86175957cfefcb850152a@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 01:44:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 01:44:36 -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.d8509e894efae532623992b5ecc2ea49@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a minimal test case: {{{#!hs module Bug where newtype ContT r m a = ContT { runContT :: (a -> m r) -> m r } foo = (`runContT` bar.baz) }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get_op runContT }}} Also reproducible on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 03:23:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 03:23:44 -0000 Subject: [GHC] #13131: add effectful version of atomicModifyMutVar# In-Reply-To: <045.8cb013f9c57e3f0110e075839473d66a@haskell.org> References: <045.8cb013f9c57e3f0110e075839473d66a@haskell.org> Message-ID: <060.275cc21c2ab23d5ada1302b80ca9990b@haskell.org> #13131: add effectful version of atomicModifyMutVar# -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: infoneeded 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 rwbarton): * status: new => infoneeded Comment: I don't understand what the semantics of this would be. How can you atomically update a `MutVar#` while allowing arbitrary side effects when computing the new value? The pure version works because we can speculatively create a thunk containing the old value in a compare-and-swap loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 03:28:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 03:28:38 -0000 Subject: [GHC] #13130: atomicModifyMutVar# has incorrect type In-Reply-To: <045.780a635d79815aa0591355968d4537c8@haskell.org> References: <045.780a635d79815aa0591355968d4537c8@haskell.org> Message-ID: <060.bcfbde34120521564b90acbb9f2e18ec@haskell.org> #13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): There's a comment about this in `compiler/prelude/primops.txt.pp`. But it should be a Haddock comment so it shows up in the documentation. A note on why we don't use an unboxed tuple would also be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 03:37:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 03:37:06 -0000 Subject: [GHC] #13135: Typechecker: the 'impossible' happened Message-ID: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> #13135: Typechecker: the 'impossible' happened -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- May be something to do with type family dependencies? Unclear - but I've attached a reduced source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 03:37:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 03:37:49 -0000 Subject: [GHC] #13135: Typechecker: the 'impossible' happened In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.c86cfe0cf0cbe862413f62c435cefb84@haskell.org> #13135: Typechecker: the 'impossible' happened -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Saulzar): * Attachment "NanoFeldspar.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 04:17:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 04:17:17 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" (was: Typechecker: the 'impossible' happened) In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.b240725977d77630883181e3496d0102@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 04:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 04:59:49 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.501939bb195fb352c71b17379300ba0e@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 dfeuer): * Attachment "passes-a0472f8" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 05:00:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 05:00:14 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.614ad7548bdefc5687e723589de3d970@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 dfeuer): * Attachment "passes-54b887b" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 05:03:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 05:03:57 -0000 Subject: [GHC] #11789: Flag suggestion does not always work In-Reply-To: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> References: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> Message-ID: <061.6ac26f12013bd5c59993bb8f6bc3d7e2@haskell.org> #11789: Flag suggestion does not always work -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | 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: #11429 | Differential Rev(s): Phab:D2978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nakaji_dayo): Replying to [comment:3 mpickering]: Sorry for the delay in updating ticket. Thank you for code review and updating the ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 05:09:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 05:09: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.b2683dd27aacb8ceeff199b709ec6ddf@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): There indeed seems to be a code size change (and you can ignore the minor 10GB wibble I mentioned; I think that was me measuring wrong). Everything is similar (but not identical) for a while, until float out. a0472f8 produced {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Data.Store.Internal]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 90,610, types: 838,922, coercions: 461,514} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Data.Store.Internal]: finished in 446.16 milliseconds, allocated 469.370 megabytes *** Simplifier [Data.Store.Internal]: Result size of Simplifier iteration=1 = {terms: 260,919, types: 1,555,565, coercions: 747,071} }}} But 54b887b produced {{{ *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Data.Store.Internal]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 90,693, types: 839,131, coercions: 461,514} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Data.Store.Internal]: finished in 942.78 milliseconds, allocated 470.779 megabytes *** Simplifier [Data.Store.Internal]: Result size of Simplifier iteration=1 = {terms: 502,024, types: 2,614,803, coercions: 1,192,064} }}} That's quite a jump indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 06:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 06:30:41 -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.8581332cf9d7ee79609025453b11f516@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 awson): My previous comment was, in fact, correct. After thorough investigations I've discovered that the crash happens when runtime linker starts to load object code into addresses higher than 2GB, thus violating small code model requirement. I see no easy ways to fix this, so, for the time being the only workaround I see is to use `-fexternal-interpreter` (thank you, people, it now works on Windows). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 06:33:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 06:33:03 -0000 Subject: [GHC] #13134: Simplifier ticks exhausted In-Reply-To: <047.364cf07e914f812155e6ad25772ad938@haskell.org> References: <047.364cf07e914f812155e6ad25772ad938@haskell.org> Message-ID: <062.415860979f56d013a7137cd4fbbe86d7@haskell.org> #13134: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: task | Status: infoneeded Priority: low | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: There's not much we can do unless you show us the code you're compiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 06:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 06:37:41 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.9c8490eedd3bca9d261ecb604690a3ae@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Per Ryan Scott's advice, I checked `-ddump-spices`. The splices define something like 48 instances without bodies. He suggests I copy/paste the splices in and strip down the package until only the interesting bits remain. The only other thing I can think of is going for `-dverbose- core2core` and trying to find the right spots. Figure it out tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 06:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 06:37:47 -0000 Subject: [GHC] #13134: Simplifier ticks exhausted In-Reply-To: <047.364cf07e914f812155e6ad25772ad938@haskell.org> References: <047.364cf07e914f812155e6ad25772ad938@haskell.org> Message-ID: <062.ddaa2f655e1c5be57b396580efc4454b@haskell.org> #13134: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: task | Status: infoneeded Priority: low | 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 fumieval): My understanding is that the default is too low so it might happen in a big project. I can try to make a program which would reproduce the panic (not sure if it's useful though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 06:38:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 06:38:25 -0000 Subject: [GHC] #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) In-Reply-To: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> References: <045.248e41e3f5874477b8d52d89ba7ec5cd@haskell.org> Message-ID: <060.c69bf74af61a8d086eec2a599e06e561@haskell.org> #13133: Real World Haskell SimpleJSON (initTc: unsolved constraints) -------------------------------------+------------------------------------- Reporter: jboydt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: #12921 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12921 Comment: Thanks for the report. This is a duplicate of #12921, which has been fixed upstream and will be merged into GHC 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 06:46:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 06:46:23 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.bd4d4e942ce434619de7f1b51bf1ead5@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be precise, here's the particular panic it gives: {{{ $ /opt/ghc/8.0.2/bin/ghci NanoFeldspar.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling NanoFeldspar ( NanoFeldspar.hs, interpreted ) NanoFeldspar.hs:122:10: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: t_a2xN }}} Reproducible on GHC 8.0.1, 8.0.2, and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 07:00:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 07:00:33 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.50f77b78537778d5790fd245cac24221@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 RyanGlScott): * Attachment "StoreImpl.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 07:00:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 07:00:41 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.45c01b5239d0b6a81ff95d5f094d0114@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 RyanGlScott): * Attachment "Store.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 07:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 07:02:35 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.710b7ed888b216af0c038c7f3f1f5f5b@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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, I strongly suspected that default methods were the culprit here, so I trimmed down `store` (and `store-core`) into two modules and compiled each with `+RTS -s`. But to my amazement, both GHC 8.0.1 and 8.0.2 allocation almost the same number of bytes on the heap with this program! So it's likely something other than default methods that are causing the issue. In any case, I hope the attached programs serve as a useful springboard for further attempts to dissect this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 07:15:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 07:15:09 -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.32092be856c00b5760e2e391834595e8@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: adamgundry (added) Comment: The culprit is commit b1884b0e62f62e3c0859515c4137124ab0c9560e (Implement DuplicateRecordFields). Thoughts, Adam? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 08:12:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 08:12:16 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal In-Reply-To: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> References: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> Message-ID: <065.d08108739a067e0e410e7e31dab7b0d9@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: T13082_good, | T13082_fail Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2941 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"4bfe3d4d13806202be7fc4a90106b200171588e6/ghc" 4bfe3d4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4bfe3d4d13806202be7fc4a90106b200171588e6" Add missing test files for T13082. Summary: Add two missing test files for T13082. The reason they were missing is because the .gitignore contains a very harmful and broad wildcard `foo*`. Why? Test Plan: make test TEST="T13082_good T13082_fail" Reviewers: austin, bgamari, simonmar, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2981 GHC Trac Issues: #13082 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 09:06:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 09:06:54 -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.e9dcb66eb679755b09c092de96b8c5ad@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Thanks for tracking this down. It looks like `get_op` is missing a case for `HsRecFld`. The unambiguous case is easy, something like: {{{#!hs get_op (L _ (HsRecFld (Unambiguous _ n))) = n }}} That should fix the bug when `DuplicateRecordFields` is disabled, at least. Unfortunately the case for `Ambiguous` (which may arise when when `DuplicateRecordFields` is enabled) is harder, because we don't know which `Name` is meant. I'll try to take a look at this, but it may not be very soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 09:07:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 09:07:46 -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.021ee8834997a036fe600fac31be15e0@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF 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 adamgundry): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 09:49:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 09:49:26 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.bf96cbdc708ef710e023216f077b3087@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Used in [https://ghc.haskell.org/trac/ghc/attachment/ticket/13133/PrettyStub.hs code] attacked to tickets, module of stubs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 10:36:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 10:36:30 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.b0ff90825509a17c35283844b42c1300@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In particular, we probably never want a pointer equality test to float out of a case on one of `reallyUnsafePtrEq`'s arguments. OK. Fix that in `primops.txt.pp` by giving `reallyUnsafePtrEq` a `can_fail` attribute. That sounds a bit odd, but read `Note [dataToTag#]` in `primops.txt.pp`, and `Note [PrimOp can_fail and has_side_effects]` in `PrimOp.h`, and expecially `Note [Transformations affected by can_fail and has_side_effects]` in `PrimOp.hs`. Would you like to do that? Add a Note obviously with your example above. Maybe make a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 10:55:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 10:55:54 -0000 Subject: [GHC] #13128: Refactor AvailInfo to be more sensible In-Reply-To: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> References: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> Message-ID: <064.7f118ea5e7a4af49d6dfcbb3bb0938df@haskell.org> #13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > `AvailInfo` has been the bane of my life for the last 12 months and I want to tame it. I'm all for making things better! But while both (1) and (2) are valid complaints, but neither quite justifies "bane". Have you been hammered with efficiency problems from (2)? Has (1) really bitten you? Can you point to code that it painful as a result? > The next plan of attack is to distinguish between `IfaceAvailInfo` and `AvailInfo`. That makes sense to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 11:02:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 11:02:24 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.b8f4d32dc3db69fcf67a50c49d1517ad@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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ideas from ignorance: Apply technique from [https://arxiv.org/abs/1610.04799 Trees That Grow] + index something by the type it generates or by sublanguage (where "efficiency" might well be a sublanguage of `pretty`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 11:07:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 11:07:12 -0000 Subject: [GHC] #13128: Refactor AvailInfo to be more sensible In-Reply-To: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> References: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> Message-ID: <064.5bae74897d4c8a01790543581d883a7e@haskell.org> #13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think (2) is significant and want to refactor to see. In another ticket pacak reported that the size of the build log was over 100mb because of warnings emitted from `ListSetOps`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 11:08:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 11:08:34 -0000 Subject: [GHC] #13128: Refactor AvailInfo to be more sensible In-Reply-To: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> References: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> Message-ID: <064.d65d47a14bdfea0e411219083bd28c26@haskell.org> #13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The new problem with this ticket now is that backpack signature files use the same interface files as regular modules. There are operations which merge signature files together and in doing so perform operations like monadically mapping over the names in `AvailTC`. I don't understand this well enough yet to refactor things properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 11:17:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 11:17:33 -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.ba0ddfe4d7af946a47c8b1a7bc69a734@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 awson): I've managed to create quick and dirty solution to make GHC work properly (basically we have to add `MEM_TOP_DOWN` flag to `VirtualAlloc` in our main `allocNew` allocation routine (see `OSMem.c`). In such a way we allocate all memory except executable (which uses `allocateExec` and `allocateImageAndTrampolines` allocation routines) from top to down leaving enough room for executable memory in low address area. OTOH, while this solves the problem for GHC itself, it can create problems for programs linked against such modified RTS: 1. MS warns that allocation from top to down may be slower; 2. If a client makes its own dynamic data execution using these data, its code will likely crash. Thus if we ever would go this way, we should modify the build system, using different allocation strategies for GHC itself and for RTS libraries distributed along with GHC. I have another couple of patches, which may or may not improve Windows allocation matters in RTS. E.g. `HeapAlloc` works well for `allocateImageAndTrampolines` saving quite a lot of memory comparing to the quite wasteful `VirtualAlloc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 11:31:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 11:31:06 -0000 Subject: [GHC] #13136: Foreign.C.Types does not have a CBool type Message-ID: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> #13136: Foreign.C.Types does not have a CBool type -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- We should add a `CBool` corresponding to C99's `bool`. Using Haskell's `Bool` can lead to unexpected errors, because it corresponds to `HsBool`, which is word-sized whereas C99 `bool` is unsigned char. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 12:06:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 12:06:37 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.be29e7b6509b1a27d99c2edf8b089fa1@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: | -------------------------------------+------------------------------------- Comment (by ethercrow): I've tried fixing this in the parser but I don't understand how to write a test for this. Parser tests in the test suite seem to check the output of compiled haskell programs or the error messages, and the way of parsing this pragma shouldn't affect either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 12:10:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 12:10:53 -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.d184367c03c715854093989eeff458cb@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF 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): Ben/David/Reid: could you fix the unambiguous case as above, add a test; and add another expect_broken test for the ambiguous case. And then assign to Adam? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 12:24:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 12:24:43 -0000 Subject: [GHC] #13128: Refactor AvailInfo to be more sensible In-Reply-To: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> References: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> Message-ID: <064.74cefde7c4821617e1b12ef1fda12979@haskell.org> #13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In another ticket pacak reported that the size of the build log was over 100mb because of warnings emitted from ListSetOps But are the warnings from usage in `AvailInfo`? Easy to find out by using `HasCallStack` info. Reason for asking: if the problem is somewhere else, it might be a better use of time to fix the somewhere else. > The new problem with this ticket now is that backpack signature files use the same interface files as regular modules. But separating `IfaceAvailInfo` from `AvailInfo` may help this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:04:39 -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.5c23506cc5398f9c3bc9da7d37e60165@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF 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 rwbarton): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:08:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:08:49 -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.a09e4bae0fe5b7b932630c2fe6d4b2c4@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: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * cc: Phyx- (added) Comment: Thanks for looking into this awson! I'm afraid this stuff flies far over my head, but Tamar might have some input. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:09:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:09:22 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.ae843e482b5b2a4ae9e82ec1688408bc@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That looks like overkill, strictly speaking, but I could definitely believe that it doesn't matter. It looks like overkill because if we have {{{#!hs foo !x !y = case x of Con1 p -> let rup1 = reallyUnsafePtrEquality# x y in ... Con2 p -> let rup2 = reallyUnsafePtrEquality# x y in ... }}} then we can safely float out just a drop: {{{#!hs foo !x !y = let rup1 = reallyUnsafePtrEquality# x y rup2 = reallyUnsafePtrEquality# x y in case x of Con1 p -> ... Con2 p -> ... }}} and then CSE the duplication out. What I don't know is if such a thing will ever occur (or matter) in practice, or whether it would be a good idea even if it did. I can certainly make the change and add some notes. There are some interactions with some discussion in #13027. At present, anyway, `reallyUnsafePtrEquality#` is only considered "safe for speculation" when its arguments are known to be forced, which sounded really weird before, but isn't that precisely when it should be safe to float it out? OTOH, this ticket reveals another issue relating to polymorphic arguments, so maybe we should make the conservative change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:15:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:15:12 -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.8236ca89bee079476bfa3b1ce96d6279@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 rwbarton): Is it possible on Windows to allocate a pool of memory addresses, below 2GB and of size, say, 1GB, without actually committing pages? I see comments in the two-step allocator about "VirtualAlloc MEM_RESERVE/MEM_COMMIT" and why it doesn't work for reserving 1TB worth of address space, but perhaps for 1GB it would be okay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:28:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:28:46 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.abce11499bbadde890f0059b40893b09@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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: #7401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): David has started a new discussion about this proposed change at the Haskell libraries mailing list here: https://mail.haskell.org/pipermail/libraries/2017-January/027590.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:32:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:32:22 -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.439ad623424337b8c67232c8dc678c7e@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 awson): Replying to [comment:6 rwbarton]: > Is it possible on Windows to allocate a pool of memory addresses, below 2GB and of size, say, 1GB, without actually committing pages? I see comments in the two-step allocator about "VirtualAlloc MEM_RESERVE/MEM_COMMIT" and why it doesn't work for reserving 1TB worth of address space, but perhaps for 1GB it would be okay. Yeah, I thought about this also. It's '''definitely''' possible, but this way we need to write a custom allocator which would commit/decommit pages inside this reserved space. This is surely doable, but not so much easily. I've also looked further down into things and found that using `MEM_TOP_DOWN` is not recommended to use for anything other than testing because of potential huge performance penalty. The good news is that `USE_LARGE_ADDRESS_SPACE` should, in fact, [http://blogs.microsoft.co.il/sasha/2016/01/05/windows-process-memory- usage-demystified/ work for latest Windows 10 versions]. `Memory.exe reserve 1000000` from the article works fine on my W10 1607. I believe W10 1511 should work either. Thus happy users of latest versions of W10 should, in theory, be able to build GHC with `USE_LARGE_ADDRESS_SPACE` enabled and run it with `heapBase` flag set to the value above, say 1GB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 14:39:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 14:39:02 -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.8a54b4f24b06a8eaeb746cda09ebef29@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 awson): Replying to [comment:7 awson]: > Yeah, I thought about this also. It's '''definitely''' possible, but this way we need to write a custom allocator which would commit/decommit pages inside this reserved space. This is surely doable, but not so much easily. Ah, we, perhaps, could reuse parts of `USE_LARGE_ADDRESS_SPACE` code for this (not using any large address space in fact). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 15:00:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 15:00:45 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs In-Reply-To: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> Message-ID: <059.c1d961029e005bfed34161a713b45d40@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: alanz Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2958 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 15:02:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 15:02:20 -0000 Subject: [GHC] #12001: RFC: Add pattern synonyms to base In-Reply-To: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> References: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> Message-ID: <066.30600e8f6280d8f1a6f5b96b15f3a08d@haskell.org> #12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): For [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List- NonEmpty.html Data.List.NonEmpty] {{{#!hs pattern NonEmpty :: NonEmpty a -> [a] pattern NonEmpty xs <- (nonEmpty -> Just xs) where NonEmpty xs = toList xs {-# COMPLETE [], NonEmpty #-} }}} using PatternSynonyms/CompleteSigs. == Uses == The pattern of destructing a `NonEmpty` value only to reassemble it pop up when using `NonEmpty` {{{#!hs f [] = ... f (x:xs) = ... (x:|xs) }}} An example is {{{#!hs -- match_groups :: [[(PatGroup,EquationInfo)]] -> DsM (NonEmpty MatchResult) -- match_groups [] = matchEmpty v ty -- match_groups (g:gs) = mapM match_group (g:|gs) match_groups :: [[(PatGroup,EquationInfo)]] -> DsM (NonEmpty MatchResult) match_groups [] = matchEmpty v ty match_groups (NonEmpty gs) = mapM match_group gs }}} Which can be abstracted into this rather useful eliminator: {{{#!hs -- match_groups = neElim (matchEmpty v ty) (mapM match_group) neElim :: c -> (NonEmpty a -> c) -> [a] -> c neElim c _ [] = c neElim _ f (NonEmpty xs) = f xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 15:07:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 15:07:16 -0000 Subject: [GHC] #13136: Foreign.C.Types does not have a CBool type In-Reply-To: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> References: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> Message-ID: <062.4d25655c23482de547c9fcf6bb8f54e2@haskell.org> #13136: Foreign.C.Types does not have a CBool type -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 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: | Differential Rev(s): Phab:D2982 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2982 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 16:03:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 16:03:22 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.94d616902c53625ce73af42eb5faba13@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5a9a1738023aeb742e537fb4a59c4aa8fecc1f8a/ghc" 5a9a173/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5a9a1738023aeb742e537fb4a59c4aa8fecc1f8a" Refine exprOkForSpeculation This patch implements two related changes, both inspired by the discussion on Trac #13027, comment:23: * exprOkForSpeculation (op# a1 .. an), where op# is a primop, now skips over arguments ai of lifted type. See the comments at Note [Primops with lifted arguments] in CoreUtils. There is no need to treat dataToTag# specially any more. * dataToTag# is now treated as a can-fail primop. See Note [dataToTag#] in primops.txt.pp I don't expect this to have a visible effect on anything, but it's much more solid than before. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 16:05:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 16:05:45 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. Message-ID: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> #13137: Dynamic linker not initialised. ----------------------------------------+--------------------------------- Reporter: djduke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: ----------------------------------------+--------------------------------- Attempting to build accelerate-llvm-1.0.0.0 cloned from the repo at https://github.com/AccelerateHS/accelerate-llvm, using: OSX 10.12.2 (Sierra) GHC 8.0.2 Command line tools for Xcode 8.2.1 [25 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [26 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) : error: : can't load .so/.DLL for: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib (dlopen(/Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib, 5): Symbol not found: __ZTIN4llvm11InstructionE Referenced from: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib Expected in: flat namespace in /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib) [27 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ... so I have. I note previous tickets for "Dynamic linker not initialised", but not clear they are relevant due to different OS etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 16:33:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 16:33:36 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.91f716a53a8aa68943a8a4fa92013e2b@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Phab:D2983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2983 Comment: Simon, I've uploaded a first shot of this at Phab:D2983. I would greatly appreciate some feedback on how to fix the remaining issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 16:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 16:41:51 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.d8e851064487e34afba9090016fcf32e@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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: #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Phyx- (added) * os: MacOS X => Unknown/Multiple * related: => #13093 Comment: I've also observed this on Windows at https://github.com/AccelerateHS/accelerate/pull/342#issuecomment-271469942. Sadly, I don't know yet how to trim `accelerate-llvm` down into a smaller testcase that also triggers this panic. But I strongly suspect that the solution is related to Phyx-'s planned fix for #13093. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 16:42:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 16:42:10 -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.3956a7dde4543ad3e1d2fcca2d22c2dd@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, #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13103 => #13103, #13093 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 17:09:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 17:09: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.98ee3b381e34af684f6748698c668d07@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, #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I have my custom ''shared libraries'' build of llvm on MinGW-w64 and `llvm-general` works just fine with it. Thus `-fshared-llvm` requirement is important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 17:36:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 17:36:26 -0000 Subject: [GHC] #13138: Clean up ghc-pkg validation warnings in build log Message-ID: <049.ca50dc09c6b5bdc241ded49d456bf621@haskell.org> #13138: Clean up ghc-pkg validation warnings in build log -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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: -------------------------------------+------------------------------------- The build log has hundreds of lines of `ghc-pkg` warnings which I imagine are due to how GHC's build system is different to normal. We should either work out why there are so many errors and fix them or if they are harmless suppress them to remove the noise from the log. {{{ binary-0.8.3.0: Warning: Unrecognized field abi-depends on line 40 27 binary-0.8.3.0: Warning: Unrecognized field abi on line 28 28 binary-0.8.3.0: Warning: Unrecognized field indefinite on line 22 29 binary-0.8.3.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/binary/dist-boot/doc/html/binary/binary.haddock doesn't exist or isn't a file 30 binary-0.8.3.0: cannot find any of ["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring) 31 binary-0.8.3.0: cannot find any of ["Data/Binary/Builder.hi","Data/Binary/Builder.p_hi","Data/Binary/Builder.dyn_hi"] (ignoring) 32 binary-0.8.3.0: cannot find any of ["Data/Binary/Get.hi","Data/Binary/Get.p_hi","Data/Binary/Get.dyn_hi"] (ignoring) 33 binary-0.8.3.0: cannot find any of ["Data/Binary/Get/Internal.hi","Data/Binary/Get/Internal.p_hi","Data/Binary/Get/Internal.dyn_hi"] (ignoring) 34 binary-0.8.3.0: cannot find any of ["Data/Binary/Put.hi","Data/Binary/Put.p_hi","Data/Binary/Put.dyn_hi"] (ignoring) 35 binary-0.8.3.0: cannot find any of ["Data/Binary/Class.hi","Data/Binary/Class.p_hi","Data/Binary/Class.dyn_hi"] (ignoring) 36 binary-0.8.3.0: cannot find any of ["Data/Binary/Internal.hi","Data/Binary/Internal.p_hi","Data/Binary/Internal.dyn_hi"] (ignoring) 37 binary-0.8.3.0: cannot find any of ["Data/Binary/Generic.hi","Data/Binary/Generic.p_hi","Data/Binary/Generic.dyn_hi"] (ignoring) 38 binary-0.8.3.0: cannot find any of ["libHSbinary-0.8.3.0.a","libHSbinary-0.8.3.0.p_a","libHSbinary-0.8.3.0-ghc7.10.3.so","libHSbinary-0.8.3.0-ghc7.10.3.dylib","HSbinary-0.8.3.0-ghc7.10.3.dll"] on library path (ignoring) 39 Cabal-1.25.0.0: Warning: Unrecognized field abi-depends on line 125 40 Cabal-1.25.0.0: Warning: Unrecognized field abi on line 106 41 Cabal-1.25.0.0: Warning: Unrecognized field indefinite on line 20 42 Cabal-1.25.0.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/Cabal/Cabal/dist-boot/doc/html/Cabal/Cabal.haddock doesn't exist or isn't a file 43 Cabal-1.25.0.0: cannot find any of ["Distribution/Backpack.hi","Distribution/Backpack.p_hi","Distribution/Backpack.dyn_hi"] (ignoring) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 18:48:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 18:48:25 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.c5403333048e4c03e35fbe89c64dd001@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by dobenour): I think that we should run loop unswitching early in the pipeline, to remove redundant heap/stack checks. How can we track aliasing information better? LLVM supports dereferencable annotations. Those might be able to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 19:47:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 19:47:24 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.7dc36c73bbc783753780aab61e81ffa3@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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: #13093 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: angerman (added) Comment: This is unrelated to the changes I'm currently working on (though in all likelihood you'll need it when not using the system linker). This seems to be coming from c3c702441137dc8f7ee0dd5ac313be96d625459a which is the stuff angerman has been working on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 19:58:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 19:58:21 -0000 Subject: [GHC] #13139: Documents not updating correctly? Message-ID: <045.9192bde334eb0234d557c11c7b682838@haskell.org> #13139: Documents not updating correctly? -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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 noticed a few broken links in the user-guide. The papers linked in the recursive-do section here: http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #the-mdo-notation are unfortunately outdated. (They moved elsewhere!) I was going to submit a git-hub patch to fix the links. After some digging, however, I found that someone else noticed the same about 8 months ago and fixed it already in this commit: http://github.com/ghc/ghc/commit/961ed26b69292f6bfb75cd2209ea0c67e77abf7b So, I'm wondering why the latest document doesn't seem to render the correct links, given this was fixed last May? Something off with the document builder? Did that commit somehow not make it into the rendered user-guide? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 19:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 19:58:56 -0000 Subject: [GHC] #13139: Documents not updating correctly? In-Reply-To: <045.9192bde334eb0234d557c11c7b682838@haskell.org> References: <045.9192bde334eb0234d557c11c7b682838@haskell.org> Message-ID: <060.02823fc10275f7226b560b353c690d7f@haskell.org> #13139: Documents not updating correctly? -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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 lerkok): * version: 8.0.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 19:59:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 19:59:25 -0000 Subject: [GHC] #13139: Documents not updating correctly? In-Reply-To: <045.9192bde334eb0234d557c11c7b682838@haskell.org> References: <045.9192bde334eb0234d557c11c7b682838@haskell.org> Message-ID: <060.84bc56ca17827f7144dac3c47f34b5e1@haskell.org> #13139: Documents not updating correctly? -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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 lerkok: @@ -2,1 +2,1 @@ - recursive-do section here: + recursive-do section are outdated: @@ -6,2 +6,0 @@ - - are unfortunately outdated. (They moved elsewhere!) New description: I noticed a few broken links in the user-guide. The papers linked in the recursive-do section are outdated: http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #the-mdo-notation I was going to submit a git-hub patch to fix the links. After some digging, however, I found that someone else noticed the same about 8 months ago and fixed it already in this commit: http://github.com/ghc/ghc/commit/961ed26b69292f6bfb75cd2209ea0c67e77abf7b So, I'm wondering why the latest document doesn't seem to render the correct links, given this was fixed last May? Something off with the document builder? Did that commit somehow not make it into the rendered user-guide? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 20:32:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 20:32:15 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.bd31954d2be79bf4774800c4594b57bf@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ryan pointed out on IRC that 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060 doesn't just change type checking for methods with default signatures—it also changes how all default methods are desugared. Previously, their code was inlined immediately; now they desugar to references to top-level bindings. I know that early inlining can reduce code size in some cases; perhaps this is one of them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 21:02:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 21:02:34 -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.4333bcd59b7dea673ae777bdae8bca28@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13103, #13093 => #13103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 21:04:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 21:04:03 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.37fa9a6de8fecbcc10ccd883f85cf156@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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 RyanGlScott): * related: #13093 => Comment: Ah, good point. I suppose //any// linker issue might trigger this bug, and #13093 just happened to be the one. Another question is why `accelerate-llvm` seems to be tickling this bug. As far as I can tell, it doesn't use any GHC plugins or anything of the sort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 21:10:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 21:10:49 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.b53c6005c28cb4e346fb5724395bc0da@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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: | -------------------------------------+------------------------------------- Comment (by Phyx-): Don't really know, I can look into it when I'm finished with my changes. But it would be far faster if @angerman takes a look. I couldn't really find a trac issue motivating the changes. So it's a bit stabbing in the dark for me atm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 21:52:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 21:52:23 -0000 Subject: [GHC] #13129: Warn about home module, not listed in commang line In-Reply-To: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> References: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> Message-ID: <059.55ad6e5f06f763dc3906fa6ddead5e1a@haskell.org> #13129: Warn about home module, not listed in commang line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2977 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The referenced issue is a closed Cabal pull request. Can you try to explain exactly what the problem is, and why special GHC support is needed to solve it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 21:52:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 21:52:55 -0000 Subject: [GHC] #13129: Warn about home module not listed on command line (was: Warn about home module, not listed in commang line) In-Reply-To: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> References: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> Message-ID: <059.41c5902d247b69cab6d52fdd216b21bc@haskell.org> #13129: Warn about home module not listed on command line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2977 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 22:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 22:13:50 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.7e487309fe563734bc1eeb695b185280@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Just as a sanity check, I did confirm that this isn't an OS-specific thing, and that this affects all GHCs built with `DYNAMIC_GHC_PROGRAMS=NO`, as I managed to receive the same error on Linux with a version of GHC HEAD built with `DYNAMIC_GHC_PROGRAMS=NO`: {{{ $ cabal build Building accelerate-llvm-1.0.0.0... Preprocessing library accelerate-llvm-1.0.0.0... ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMSupport.a: unknown symbol `_ZGVZN4llvm7hashing6detail18get_execution_seedEvE4seed' ghc-stage2: Could not on-demand load symbol '_ZN4llvm16FoldingSetNodeID10AddIntegerEj' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMSupport.a: unknown symbol `_ZN4llvm16FoldingSetNodeID10AddIntegerEj' ghc-stage2: Could not on-demand load symbol '_ZNK4llvm5APInt13EqualSlowCaseEm' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMCore.a: unknown symbol `_ZNK4llvm5APInt13EqualSlowCaseEm' ghc-stage2: Could not on-demand load symbol '_ZNK4llvm5Value7getNameEv' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMNVPTXCodeGen.a: unknown symbol `_ZNK4llvm5Value7getNameEv' ghc-stage2: Could not on-demand load symbol '_ZN4llvm3sys10SmartMutexILb0EED1Ev' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMSupport.a: unknown symbol `_ZN4llvm3sys10SmartMutexILb0EED1Ev' ghc-stage2: Could not on-demand load symbol '_ZNK4llvm17ManagedStaticBase21RegisterManagedStaticEPFPvvEPFvS1_E' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMCore.a: unknown symbol `_ZNK4llvm17ManagedStaticBase21RegisterManagedStaticEPFPvvEPFvS1_E' ghc-stage2: Could not on-demand load symbol '_ZN4llvm12PassRegistry15getPassRegistryEv' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMLTO.a: unknown symbol `_ZN4llvm12PassRegistry15getPassRegistryEv' ghc-stage2: Could not on-demand load symbol '_ZTVN4llvm17DiagnosticPrinterE' ghc-stage2: /usr/lib/llvm-3.8/lib/libLLVMCore.a: unknown symbol `_ZTVN4llvm17DiagnosticPrinterE' ghc-stage2: Could not on-demand load symbol 'LLVMIsMultithreaded' ghc-stage2: /home/rgscott/.cabal/lib/x86_64-linux-ghc-8.1.20170116/llvm- general-3.8.0.0-ANwvTQYpoC83vup0OmjiSV/HSllvm- general-3.8.0.0-ANwvTQYpoC83vup0OmjiSV.o: unknown symbol `LLVMIsMultithreaded' [25 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Monad[boot] ( Data/Array/Accelerate/LLVM/CodeGen/Monad.hs-boot, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Monad.o-boot ) [26 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) : error: ghc-stage2: unable to load package `llvm-general-3.8.0.0' [27 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170116 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [34 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170116 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [35 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.IR ( Data/Array/Accelerate/LLVM/CodeGen/IR.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/IR.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170116 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 22:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 22:24:20 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.edb2236abce4bb19c4537fbfc301e4ab@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: | -------------------------------------+------------------------------------- Comment (by goldfire): The previous string of comments are very very helpful. I have a good understanding of the issues here. I also don't have any strong opinions about good vs bad design, so I'm happy to let you folks debate this. As for my student: this student is fairly new to me (and to Haskell), and we have yet to have our first meeting in the spring semester. My guess is that she will be able to work well with a rather-concrete specification -- but it seems we are moving in that direction (modulo challenges with #10735). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 16 23:06:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jan 2017 23:06:58 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.a86865f6d1e2ec2f51f178004fb09506@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Phab:D2983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider {{{ class C a b where op :: forall p q. (Ord a, D p q) => a -> b -> (a,b) default op :: forall r. (E r) => a -> b -> (a,b) }}} We are expecting the part after the `=>` to be identical. In `check_dm` in `checkValidClass` we have in hand: * `sel_id :: forall aa bb. C aa bb => forall p q. (Ord p, D p q) => aa -> bb -> p -> (aa,bb)`. Note that `sel_id` always has this form: see `sel_ty` in `MkId.mkDictSelId` * Inside class `C a b` we have a `GemericDM (forall r s. (E r) => a -> b -> s -> (a,b)`. This is passed to `check_dm`. Notice that, as commented with `Class.DefMethInfo`, the `ty` in `(GenericDM ty)` is ''not'' quantified over the class variables `a` and `b`. But `sel_id` ''is'' so quantified, and in principle its foralls, here `aa` and `bb`, might be different to the class tyvars `a` and `b`. (This will never happen in practice, but still.) What we want is to match up these two types {{{ From sel_id: C aa bb => aa -> bb -> p -> (aa,bb) From GenericDM: C a b => a -> b -> s -> (a, b) }}} This is a '''one-way match''': use `tcMatchTy`. Not unification! We need the `C a b` part to match up `a` with `aa` and `b` with `bb`. If successful we'll emerge with a mapping `[a -> aa, b -> bb, s -> p]`. Is that enough? No: we need to ensure that each variable in the domain of the substitution maps to a distinct type variable in the range. For example `[s -> Int]` would not be OK. I think `TcValidity.allDistinctTyVars` is what you want. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 02:15:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 02:15:52 -0000 Subject: [GHC] #9137: A way to match RULES only for literals In-Reply-To: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> References: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> Message-ID: <061.0c9e240fb7efe5d00de85da17ce33b75@haskell.org> #9137: A way to match RULES only for literals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 02:28:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 02:28:18 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.d50c6e8911e315ee496be446b6cfead3@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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: | -------------------------------------+------------------------------------- Comment (by angerman): I'm a bit at a loss here, as I do not see the connection yet. All the change did, was remove the need to call reinitializeGlobals from plugins, which was done through the saveLinkerGlobals, restoreLinkerGlobals; essentially doing what the now deleted comment from that commit said. The diff did turn the MVar PersistentLinkerState into a sharedGlobal, I however do believe that the issue might more likely be with the calling (or not calling of) getOrSetLibHSghcInitLinkerDone. Phyx- if you could take a look, that would be great, as I would likely only find time to investigate this earliest next week :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 04:17:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 04:17:56 -0000 Subject: [GHC] #13111: maintainer-clean should clean build.mk In-Reply-To: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> References: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> Message-ID: <061.e3d342a041d23c5c59694b594127713e@haskell.org> #13111: maintainer-clean should clean build.mk -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Build System | 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:D2963 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): There were objections to changing this behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 04:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 04:18:12 -0000 Subject: [GHC] #13111: maintainer-clean should clean build.mk In-Reply-To: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> References: <046.efec1cc3837eace689c353b98f3d2a7f@haskell.org> Message-ID: <061.38ff991d54ac117b7214b8657a37e1f0@haskell.org> #13111: maintainer-clean should clean build.mk -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Build System | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2963 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 06:23:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 06:23: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.21ea31ac68c12303b6196bc547b29a18@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Building on Ryan's `StoreImpl` attachment, I've come up with `Store- Tuples` and `Store-Random`. `Store-Tuples` is very simple, and demonstrates a roughly 50% increase in allocations, but not an increase in residency. `Store-Random` is somewhat more involved, and demonstrates increases in both (although it's clearly not the biggest culprit). I hope these will at least help point toward the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 06:23:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 06:23:34 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.81b352fe971529d1b7d377f7c2afaf3d@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 dfeuer): * Attachment "Store-Tuples.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 06:23:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 06:23:47 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.01be27cd6e5b0fedd8f8b5f4c0bc4016@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 dfeuer): * Attachment "Store-Random.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 09:09:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 09:09:08 -0000 Subject: [GHC] #13129: Warn about home module not listed on command line In-Reply-To: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> References: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> Message-ID: <059.b40c15a3cd6297ee0ca9bb780fcd5a8f@haskell.org> #13129: Warn about home module not listed on command line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: => Yuras @@ -2,1 +2,1 @@ - https://github.com/haskell/cabal/pull/1455 + https://github.com/haskell/cabal/issues/1746 New description: It is an attempt to fix this cabal issue: https://github.com/haskell/cabal/issues/1746 Basically, when user fails to list all modules in `exposed-modules` or `other-modules`, cabal produces broken package. The idea of the fix is to teach GHC to warn about home modules (not from an other package), that are not explicitly listed in command line. Option name `-Wmissing-home-modules` is a subject for bikeshedding. -- Comment: Oops, the link was wrong, sorry. The problem: when user fail to list a module in cabal file, then the package successfully builds, but the corresponding `.o` file is not included into the library. As a result, the package is unusable. One can argue that it is Cabal issue, and GHC has nothing to do with that. But fixing it on Cabal side is relatively hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 15:01:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 15:01:05 -0000 Subject: [GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage In-Reply-To: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> References: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> Message-ID: <064.0fc217d0bf9b34079057c941fba88d19@haskell.org> #13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8809 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have a [[https://gist.github.com/bgamari/efb89da400451825357415ff85ccb078|parser]] for the testsuite driver output which extracts the failing testcases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 15:02:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 15:02:15 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.834af3f3f34f9980aa88753ff4c17931@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T12921 Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 15:05:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 15:05:30 -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.d2652c491fc9923e9bae9d7243aa6448@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 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 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => rename/should_compile/T13132 * differential: => Phab:D2985 Comment: I posted a diff fixing the unambiguous case as described above. I don't understand these extensions well enough to know whether it is actually possible for an ambiguous record selector to pass the renamer to this point, so I didn't add a failing test case for the ambiguous record field case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 15:05:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 15:05:58 -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.c3add1a71c657f83c1d5abd858fb9263@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: rwbarton => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 15:06:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 15:06:13 -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.cbe71b8a53cd3d0e29fafe9a14b1eb63@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 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 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => adamgundry -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 16:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 16:11:26 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.3884a66f6aa6145c8fe8642bd87235f8@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michelmno): Replying to [comment:6 trommler]: > In #12469 I wondered if qemu is doing something odd. @michelmno did you run your tests on bare hardware? I tested on a ppc64le bare-metal machine (without qemu) and I still have core of ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 16:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 16:43:05 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.812e40ec824dca618827e25fa8a5c845@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: infoneeded => new Comment: Replying to [comment:7 michelmno]: > Replying to [comment:6 trommler]: > > In #12469 I wondered if qemu is doing something odd. @michelmno did you run your tests on bare hardware? > > I tested on a ppc64le bare-metal machine (without qemu) and I still have core of ghc. Thank you for the info! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 16:43:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 16:43:20 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.dc1e38f8ce1d62a1e36e410ec6fcc9ea@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK this is a real bug, to do with the implementation of injective type families. I'm struggling with time, but I at least understand the problem -- thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 16:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 16:47:17 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.562138899dc91ee31caa876037ef7126@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => Comment: I have no idea what might be causing this issue and other random panics I see on openSUSE Build Service. For now I am disowning the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 17:06:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 17:06: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.90b815b092b308ea0ce16b184e96127e@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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 17:23:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 17:23:21 -0000 Subject: [GHC] #10599: Template Haskell doesn't allow `newName "type"` In-Reply-To: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> References: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> Message-ID: <063.83419fc31d43ffde31754c5c4caadedc@haskell.org> #10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2 either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 18:15:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 18:15:26 -0000 Subject: [GHC] #12417: API annotations for unboxed sums needs reworking In-Reply-To: <043.00b31e92686f5920efa6f831cd588891@haskell.org> References: <043.00b31e92686f5920efa6f831cd588891@haskell.org> Message-ID: <058.246ee90f3dd0a7d7434bad8c611c8380@haskell.org> #12417: API annotations for unboxed sums needs reworking -------------------------------------+------------------------------------- Reporter: osa1 | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"38f289fa2a8715d2d5869e144b764c35cba16c6a/ghc" 38f289fa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38f289fa2a8715d2d5869e144b764c35cba16c6a" Fix API Annotations for unboxed sums An unboxed tuple such as (# | b | | | | | #) Ends up in the parser via `tup_exprs` as Sum 2 7 lexp where `lexp` is a `LHsExpr` From an API annotation perspective, the 5 `AnnVbar`s after the `b` were attached to `lexp`, but the leading `AnnVbar`s did not have a home. This patch attaches them all to the the parent tuple expression. The first (alt - 1) of them come before `lexp`, and the remaining (arity - alt) come after. Test Plan: ./validate Reviewers: osa1, austin, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2968 GHC Trac Issues: #12417 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 19:45:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 19:45:04 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack Message-ID: <045.f307b75ae2f892817529512243583cc2@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack hs- | Operating System: Unknown/Multiple boot | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I understand correctly, GHC's three currently supported roles follow the following subtyping relation: `phantom <: representational <: nominal`. So it would make sense to adjust Backpack and `hs-boot` files to handle this subtyping relation appropriately. Here's my proposal. * 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. I actually don't know if the proofs about roles actually say anything about this subtyping relation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 20:15:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 20:15:16 -0000 Subject: [GHC] #13141: Don't check for Perl in ./configure when not splitting objects Message-ID: <047.a2722241ec56f4afc6afd14ced53477d@haskell.org> #13141: Don't check for Perl in ./configure when not splitting objects -------------------------------------+------------------------------------- Reporter: dobenour | Owner: dobenour Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- GHC needs Perl for exactly two reasons: - To run `boot` and the Autotools - For the splitter As such, there is no reason to check for Perl in `./configure` unless split-objs is supported. Even then, Perl is optional. The current check most likely comes from the days of the Evil Mangler. I'll take this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 20:31:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 20:31:13 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.1217a86493a1e3a42f7dbaf74ead729b@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | 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: | -------------------------------------+------------------------------------- Description changed by dobenour: @@ -8,0 +8,1 @@ + {{{ @@ -43,1 +44,1 @@ - + }}} New description: Attempting to build accelerate-llvm-1.0.0.0 cloned from the repo at https://github.com/AccelerateHS/accelerate-llvm, using: OSX 10.12.2 (Sierra) GHC 8.0.2 Command line tools for Xcode 8.2.1 {{{ [25 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [26 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) : error: : can't load .so/.DLL for: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib (dlopen(/Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib, 5): Symbol not found: __ZTIN4llvm11InstructionE Referenced from: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib Expected in: flat namespace in /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib) [27 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} ... so I have. I note previous tickets for "Dynamic linker not initialised", but not clear they are relevant due to different OS etc. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 21:24:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 21:24:49 -0000 Subject: [GHC] #13142: GHC emits enormous core starting with 'Arity decrease' Message-ID: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> #13142: GHC emits enormous core starting with 'Arity decrease' ----------------------------------------+--------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: ----------------------------------------+--------------------------------- I discovered this when building [https://github.com/commercialhaskell/stack/commit/f117ffb034658e3e1c3fea2a88972c685b4558e1 stack] by stack on windows 10. I want to find problem area, but I can't even catch a clue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 21:25:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 21:25:33 -0000 Subject: [GHC] #13142: GHC emits enormous core starting with 'Arity decrease' In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.555d00a1819d54076c99df0bea0012af@haskell.org> #13142: GHC emits enormous core starting with 'Arity decrease' ---------------------------------+---------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by jeiea): * Attachment "error.7z" added. stack verbose output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 21:37:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 21:37:32 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.2186a7b599b938dc6e3d26fbaea12773@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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): Phab:D1012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b1726c1194f1ed35dffc83304260b3b29abd0c53/ghc" b1726c11/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b1726c1194f1ed35dffc83304260b3b29abd0c53" Bitmap: Use foldl' instead of foldr These are producing StgWords so foldl' is the natural choice. I'm not sure how I didn't notice this when I wrote D1041. Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2955 GHC Trac Issues: #7450 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 21:37:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 21:37:32 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.c8bdfa2a49ef3bc2fd86e5164bb432d8@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d5cd505bc484edee3dbd5d41fb7a27c2e18d528d/ghc" d5cd505b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5cd505bc484edee3dbd5d41fb7a27c2e18d528d" event manager: Don't worry if attempt to wake dead manager fails This fixes #12038, where the TimerManager would attempt to wake up a manager that was already dead, resulting in setnumcapabilities001 occassionally failing during shutdown with unexpected output on stderr. I'm frankly still not entirely confident in this solution but perhaps it will help to get a few more eyes on this. My hypothesis is that the TimerManager is racing: thread TimerManager worker ------- -------------------- requests that thread manager shuts down begins to clean up, closing eventfd calls wakeManager, which tries to write to closed eventfd To prevent this `wakeManager` will need to synchronize with the TimerManger worker to ensure that the worker doesn't clean up the `Control` while another thread is trying to send a wakeup. However, this would add a bit of overhead on every timer interaction, which feels rather costly for what is really a problem only at shutdown. Moreover, it seems that the event manager (e.g. `GHC.Event.Manager`) is also afflicted by a similar race. This patch instead simply tries to catch the write failure after it has happened and silence it in the case that the fd has vanished. It feels rather hacky but it seems to work. Test Plan: Run `setnumcapabilities001` repeatedly Reviewers: hvr, austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2957 GHC Trac Issues: #12038 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 21:37:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 21:37:32 -0000 Subject: [GHC] #13120: Can't compile HEAD with ghc-7.10.1 In-Reply-To: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> References: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> Message-ID: <059.3915e351aad74e192faf561da027d6fe@haskell.org> #13120: Can't compile HEAD with ghc-7.10.1 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: bug | Status: new Priority: normal | Milestone: 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): Phab:D2976 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2b61f52a0d0d636fb468756728c3ee0f5def8304/ghc" 2b61f52a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b61f52a0d0d636fb468756728c3ee0f5def8304" Unbreak build with ghc-7.10.1 Test Plan: build with ghc-7.10.1 Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2976 GHC Trac Issues: #13120 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 22:36:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 22:36:58 -0000 Subject: [GHC] #13120: Can't compile HEAD with ghc-7.10.1 In-Reply-To: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> References: <044.6b6993928b5bbeb11aacca24fbd72bbe@haskell.org> Message-ID: <059.e95a6049be46fea56b7d35cf9701654a@haskell.org> #13120: Can't compile HEAD with ghc-7.10.1 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2976 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 Tue Jan 17 23:02:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 23:02:01 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper Message-ID: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Currently we do no worker/wrapper on a NOINLINE thing. In `WorkWrap`: {{{ tryWW dflags fam_envs is_rec fn_id rhs | isNeverActive inline_act -- No point in worker/wrappering if the thing is never inlined! -- Because the no-inline prag will prevent the wrapper ever -- being inlined at a call site. }}} But if we have, say, {{{ {-# NOINLINE f #-} f (x,y) = error (show x) g True p = f p g False p = snd p + 1 }}} then strictness analysis will discover `f` is strict, and `g`, but ''because `f` has no wrapper'', the worker for `g` will rebox the thing. So we get {{{ f (x,y) = error (show x) $wg b x y = let p = (x,y) -- Yikes! Reboxing! in case b of True -> f p False -> y + 1 g b p = case p of (x,y) -> $wg b x y }}} 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. --------------------------- This actually happens! In `GHC.Arr` we have {{{ {-# NOINLINE indexError #-} indexError :: Show a => (a,a) -> a -> String -> b indexError rng i tp = error (...) index b i | inRange b i = unsafeIndex b i | otherwise = indexError b i "Char" }}} The `inRange` generates multiple alternatives, which the `indexError` is duplicated into, and exactly this phenomenon takes place. Eric (gridaphobe) offered this standalone example {{{ module Err where tabulate :: (Int -> a) -> (Int, Int) -> [Int] tabulate f (l,u) = array (l,u) [l..u] {-# INLINE array #-} array :: (Int, Int) -> [Int] -> [Int] array (l,u) is = [index (l,u) i | i <- is] {-# INLINE index #-} index :: (Int, Int) -> Int -> Int index b@(l,h) i | l <= i && i < h = 0 | otherwise = indexError b i 0 {-# NOINLINE indexError #-} indexError :: (Int, Int) -> Int -> Int -> b indexError rng i tp = error (show rng) }}} Compile this with GHC 8, and shudder at the terrible code we get for `$wtabulate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 17 23:12:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jan 2017 23:12:11 -0000 Subject: [GHC] #13144: FoatOut is not floating bottoming expressions properly Message-ID: <046.9f2c662c794331eaa161d287a4179fe3@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 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 part of Eric's program in #13143, and pretty much exactly what is in `GHC.Arr`. {{{ {-# INLINE index #-} index :: (Int, Int) -> Int -> Int index b@(l,h) i | l <= i && i < h = 0 | otherwise = indexError b i 0 {-# NOINLINE indexError #-} indexError :: (Int, Int) -> Int -> Int -> b indexError rng i tp = error (show rng) }}} Before float-out we have {{{ index = \ (b_ay8 :: (Int, Int)) (i_ayb :: Int) -> case b_ay8 of wild_Xe { (l_ay9, h_aya) -> case && (leInt l_ay9 i_ayb) (ltInt i_ayb h_aya) of { False -> indexError @ Int wild_Xe i_ayb (I# 0#); True -> GHC.Types.I# 0# } } }}} and after float-out we see {{{ index = \ (b_ay8 :: (Int, Int)) (i_ayb :: Int) -> case b_ay8 of wild_Xe { (l_ay9, h_aya) -> case && (leInt l_ay9 i_ayb) (ltInt i_ayb h_aya) of { False -> indexError @ Int b_ay8 i_ayb lvl_s2cd; True -> GHC.Types.I# 0# } } }}} We've floated the `(I# 0#)`. ''But we should have floated the entire call to `indexError` thus'': {{{ False -> lvl_xxx b_ay8 i_ayb }}} with {{{ lvl_xxx b i = indexError @Int b i (I# 0#) }}} Why? Because it makes the expression smaller and moves the error handling code out of the way. Float-out makes some attempt to to this, but it's not right yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 01:39:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 01:39:35 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions Message-ID: <051.129037e11cb5648c9e72e783766a6946@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example, in the [Prelude](https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html) docs we have a section called "Input functions" in which only one of the four values is a function: {{{ getChar :: IO Char getLine :: IO String getContents :: IO String interact :: (String -> String) -> IO () }}} Referring to non-function values (particularly of type `IO`) as "functions" is often a sign that beginners haven't fully grasped some concepts about purity, so I think it's important to clean up our own language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 01:40:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 01:40:45 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.c125cde88e36733b8feef0d86edd8518@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: @@ -2,3 +2,3 @@ - [Prelude](https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html) - docs we have a section called "Input functions" in which only one of the - four values is a function: + [https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html + Prelude] docs we have a section called "Input functions" in which only one + of the four values is a function: New description: For example, in the [https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html Prelude] docs we have a section called "Input functions" in which only one of the four values is a function: {{{ getChar :: IO Char getLine :: IO String getContents :: IO String interact :: (String -> String) -> IO () }}} Referring to non-function values (particularly of type `IO`) as "functions" is often a sign that beginners haven't fully grasped some concepts about purity, so I think it's important to clean up our own language. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 01:49:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 01:49:03 -0000 Subject: [GHC] #13146: Doc for RealWorld refers to non-existent "ptrArg" Message-ID: <051.16114a56d2c2d800656a0dcdf2ae3831@haskell.org> #13146: Doc for RealWorld refers to non-existent "ptrArg" -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The haddock for `RealWorld` says: > `RealWorld` is deeply magical. It is ''primitive'', but it is not ''unlifted'' (hence `ptrArg`). We never manipulate values of type `RealWorld`; it's only used in the type system, to parameterise `State#`. The "(hence `ptrArg`)" doesn't seem to make any sense. There is no identifer named `ptrArg` anywhere in the GHC repository. Is this a typo, or a reference to something that no longer exists? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 02:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 02:06:07 -0000 Subject: [GHC] #13147: Formatting is broken in Exceptions section of GHC.Prim haddock Message-ID: <051.0397004541ccc405db287acf386a2c03@haskell.org> #13147: Formatting is broken in Exceptions section of GHC.Prim haddock -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something seems to have gone wrong with how this documentation is rendered to HTML. https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:14 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 02:07:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 02:07:17 -0000 Subject: [GHC] #13147: Formatting is broken in Exceptions section of GHC.Prim haddock In-Reply-To: <051.0397004541ccc405db287acf386a2c03@haskell.org> References: <051.0397004541ccc405db287acf386a2c03@haskell.org> Message-ID: <066.2f7e8d43fb11dc1e999636cdd1e6fecf@haskell.org> #13147: Formatting is broken in Exceptions section of GHC.Prim haddock -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chris-martin): * Attachment "ex.png" added. Screenshot of the haddock -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 02:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 02:42:51 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.82a651faf687ac156ced2df48355b415@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: @@ -13,0 +13,3 @@ + In that case, I suggest we rename the sections "Input functions" and + "Output functions" to simply "Input" and "Output". + New description: For example, in the [https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html Prelude] docs we have a section called "Input functions" in which only one of the four values is a function: {{{ getChar :: IO Char getLine :: IO String getContents :: IO String interact :: (String -> String) -> IO () }}} In that case, I suggest we rename the sections "Input functions" and "Output functions" to simply "Input" and "Output". Referring to non-function values (particularly of type `IO`) as "functions" is often a sign that beginners haven't fully grasped some concepts about purity, so I think it's important to clean up our own language. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 02:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 02:43:23 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.6604aa14ab3c8b08d76448b7cc107d2d@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: @@ -0,0 +1,5 @@ + Referring to non-function values (particularly of type `IO`) as + "functions" is often a sign that beginners haven't fully grasped some + concepts about purity, so I think it's important to clean up our own + language. + @@ -15,5 +20,0 @@ - - Referring to non-function values (particularly of type `IO`) as - "functions" is often a sign that beginners haven't fully grasped some - concepts about purity, so I think it's important to clean up our own - language. New description: Referring to non-function values (particularly of type `IO`) as "functions" is often a sign that beginners haven't fully grasped some concepts about purity, so I think it's important to clean up our own language. For example, in the [https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html Prelude] docs we have a section called "Input functions" in which only one of the four values is a function: {{{ getChar :: IO Char getLine :: IO String getContents :: IO String interact :: (String -> String) -> IO () }}} In that case, I suggest we rename the sections "Input functions" and "Output functions" to simply "Input" and "Output". -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 03:02:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 03:02:31 -0000 Subject: [GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals In-Reply-To: <045.3b1e3cade00998df210490cd104467e8@haskell.org> References: <045.3b1e3cade00998df210490cd104467e8@haskell.org> Message-ID: <060.6b26cb549e8e28b895f7af28dec82c48@haskell.org> #13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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): How would this new capability be accessed? I don't believe users can write non-`Rational` literals in Haskell, and so I wouldn't expect Template Haskell to be able to either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 03:25:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 03:25:56 -0000 Subject: [GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals In-Reply-To: <045.3b1e3cade00998df210490cd104467e8@haskell.org> References: <045.3b1e3cade00998df210490cd104467e8@haskell.org> Message-ID: <060.022bf46eaed3aa937daf095bcfe7bf80@haskell.org> #13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 That is a good point! But if TH aims at being able to produce constants of floats as a valid splice, then this will be an issue. Imagine a use case where someone uses template-haskell to "optimize" or "stabilize" numeric expressions. For instance, something like Herbie: http://herbie.uwplse.org/. There's already a GHC plugin for that: https://github.com/mikeizbicki/HerbiePlugin. One can easily imagine doing a similar transformation via TH, and having access to arbitrary floating constants would be useful. There would be no easy way to write that in TH today as all the "magic" constants would have to be converted to rationals, thus having anomalies. The other place this came up is in the FloatingHex library: https://hackage.haskell.org/package/FloatingHex-0.4. Currently this isn't a big issue there since literals supported are typically only positive ones, but one can imagine having a similar quasi-quoter that supported negative literals as well. Unfortunately, you cannot represent numbers such as "-0.0" (negative-zero!), as there is no way to write that as a rational number. (Note that negative-zero is a "valid" float, which can be told apart from the good old positive-zero.) I wouldn't go as far as saying that this is a huge shortcoming, but I don't see why TH can't just use a good old double/float there instead of requiring a Rational? Is there a good reason for requiring a Rational there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 04:03:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 04:03:28 -0000 Subject: [GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals In-Reply-To: <045.3b1e3cade00998df210490cd104467e8@haskell.org> References: <045.3b1e3cade00998df210490cd104467e8@haskell.org> Message-ID: <060.cc4d3bd44187c2308637e65b17def53c@haskell.org> #13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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): > One can easily imagine doing a similar transformation via TH, and having access to arbitrary floating constants would be useful. There would be no easy way to write that in TH today as all the "magic" constants would have to be converted to rationals, thus having anomalies. This doesn't make sense to me: any ordinary floating point value (i.e. not negative zero, infinity or NaN) can be exactly represented as a rational number. For those special floating point values, you could just generate an expression that evaluates to the `Double` you need, like `1.0 / 0.0`. Do you really need a literal specifically? In short, I don't see a real use case here. > I wouldn't go as far as saying that this is a huge shortcoming, but I don't see why TH can't just use a good old double/float there instead of requiring a Rational? Is there a good reason for requiring a Rational there? GHC doesn't use `Double` in any AST type. All floating point literals are represented internally as `Rational`. Considering the nasty and potentially platform-dependent semantics of `Double`, this is a good thing. Imagine cross-compiling to a hypothetical platform with 128-bit `Double`s on a platform that doesn't support that. (It's also certainly necessary to represent floating-point literals as `Rational` rather than `Double` or any other fixed-size data type, since `Rational` is itself a valid type for a floating-point literal!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 04:19:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 04:19:51 -0000 Subject: [GHC] #13126: Support for hexadecimal floats In-Reply-To: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> References: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> Message-ID: <060.0fae5e6b2c21d1ff467d929893bacc75@haskell.org> #13126: Support for hexadecimal floats -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by lerkok): Note that there is now a "GHC proposal" under discussion for this: https://github.com/ghc-proposals/ghc-proposals/pull/37 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 04:26:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 04:26:03 -0000 Subject: [GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals In-Reply-To: <045.3b1e3cade00998df210490cd104467e8@haskell.org> References: <045.3b1e3cade00998df210490cd104467e8@haskell.org> Message-ID: <060.7b1d31b85b13997d8045b8c6e98cb89d@haskell.org> #13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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): @rwbarton Good point. I think it really comes down to special things like `NaN`, `Infinity` and `negative-zero` where the Rational representation just does not suffice. But perhaps that shortcoming doesn't warrant changing the AST and complicating the matters. I'm happy with a `wont-fix` decision here. This is clearly not the highest priority item in the TH story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 06:06:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 06:06:54 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.5d0fa502c186a6f75aae0bac9a52a5b4@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- 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 gridaphobe): Hi Simon, I'm a bit confused by your simplified example. On HEAD I get {{{ g = \ @ a @ p $dNum $dShow ds p1 -> case ds of { False -> + $dNum (case p1 of { (ds1, y) -> y }) (fromInteger $dNum g1); True -> f $dShow p1 } }}} No reboxing (or worker) in sight. But if I pattern match on the pair inside `g` {{{ g True (x,y) = f (x,y) g False (x,y) = x + 1 }}} I get {{{ $wg = \ @ b @ p w w1 w2 ww -> case w2 of { False -> + w ww (fromInteger w g2); True -> f w1 (ww, g1) } g = \ @ b @ p w w1 w2 w3 -> case w3 of { (ww1, ww2) -> $wg w w1 w2 ww1 } }}} which does do the needless reboxing. Unfortunately, removing the `isNeverActive` case in `tryWW` does not change the result, and glancing through `-dverbose-core2core` it doesn't appear that we end up performing W/W on `f`. It also doesn't improve the situation for the GHC.Arr example as you've written it, though interestingly it '''does''' improve over HEAD if you define `indexError` as a simple diverging loop {{{ indexError rng i tp = indexError rng i tp }}} rather than an explicit `error` call. Furthermore, even though the motivating example is not yet improved, there are some small gains in nofib {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.9% -0.3% -16.9% -24.7% -2.4% Max 0.0% 0.0% +14.5% +15.8% +0.9% Geometric Mean -0.1% -0.0% +0.4% -1.2% -0.0% }}} It seems we're on the right track, but there must be another missing piece to the puzzle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 06:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 06:41:51 -0000 Subject: [GHC] #12417: API annotations for unboxed sums needs reworking In-Reply-To: <043.00b31e92686f5920efa6f831cd588891@haskell.org> References: <043.00b31e92686f5920efa6f831cd588891@haskell.org> Message-ID: <058.02c0cd47c9a55934b68cdb7c1761f102@haskell.org> #12417: API annotations for unboxed sums needs reworking -------------------------------------+------------------------------------- Reporter: osa1 | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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:D2968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 08:16:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 08:16:06 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.36fec4fabefb0871b12ce52384e9e41a@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: closed => new * resolution: fixed => Comment: @bgamari: I think the original issue that this ticket describes still exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 11:38:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 11:38:46 -0000 Subject: [GHC] #13148: Adding weak pointers to non-mutable unboxed values segfaults Message-ID: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> #13148: Adding weak pointers to non-mutable unboxed values segfaults -------------------------------------+------------------------------------- Reporter: mboes | 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: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import Foreign import GHC.Base import GHC.IORef import GHC.Ptr import GHC.STRef import System.Mem main = do p@(Ptr p#) <- mallocBytes 10 r@(IORef (STRef r#)) <- newIORef True IO $ \s -> case mkWeakNoFinalizer# r# () s of (# s1, w #) -> (# s1, () #) performGC }}} This program works fine. But if I `mkWeakNoFinalizer#` to `#p` instead of `#r` then it '''segfaults'''. That is, I can attach a weak pointer to a `MutVar#`, as well as to a `MVar#`, but not any other unboxed type, including pointer addresses. The documentation says "Finalizers ''can'' be used reliably for types that are created explicitly and have identity, such as IORef and MVar". But a) I don't know that "types that have identity" is defined anywhere, b) this doesn't say that weak pointers ''cannot'' be used for anything else. Should I be able to create weak pointers to any unboxed value? If not, I guess this is mostly a documentation bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 12:44:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 12:44:33 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.90c35958ce85a20e90388b9346cb3759@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michelmno): The trials I made in [comment:7 comment 7] was with ghc 8.0.1 with following patches (as per spec file in OBS https://build.opensuse.org/package/view_file/devel:languages:haskell/ghc/ghc.spec?expand=1 {{{ # PATCH-FIX-UPSTREAM D2495.patch peter.trommler at ohm-hochschule.de -- Add missing memory barrier on mutable variables. See https://ghc.haskell.org/trac/ghc/ticket/12469 for details. Backport of upstream fix for ghc 8.0.2. Patch27: D2495.patch # PATCH-FIX_UPSTREAM 0001-StgCmmPrim-Add-missing-write-barrier.patch peter.trommler at ohm-hochschule.de -- Add missing write barrier on mutable arrays. Patch28: 0001-StgCmmPrim-Add-missing-write-barrier.patch # PATCH-FIX_UPSTREAM ghc-no-madv-free.patch psimons at suse.com -- Fix "unable to decommit memory: Invalid argument" errors. See https://ghc.haskell.org/trac/ghc/ticket/12495 for details. Patch29: ghc-no-madv-free.patch # PATCH-FIX-UPSTREAM 0001-PPC-CodeGen-fix-lwa-instruction-generation.patch peter.trommler at ohm-hochschule.de -- Fix PPC codegen: Fixes ghc- zeromq4-haskell build on 64-bit PowerPCs Patch30: 0001-PPC-CodeGen-fix-lwa-instruction-generation.patch }}} The core dumps as reported by systemd-coredump are not always at same address (as per journalctl output) {{{ Jan 17 15:27:42 abanc kernel: ghc_worker[12624]: unhandled signal 11 at 38425a003c4c02f4 nip 38425a003c4c02f4 lr 00003fff8da98774 code 30001 Jan 17 15:28:01 abanc systemd-coredump[12677]: Process 12485 (Setup) of user 1000 dumped core. Jan 17 15:31:25 abanc kernel: ghc_worker[12822]: unhandled signal 11 at 0000000000000000 nip 00003fff8430b4f4 lr 00003fff84308774 code 30001 Jan 17 15:31:37 abanc systemd-coredump[12828]: Process 12793 (Setup) of user 1000 dumped core. Jan 17 15:32:34 abanc systemd-coredump[12827]: Process 12795 (ghc) of user 1000 dumped core. Jan 17 15:34:18 abanc systemd-coredump[12676]: Process 12487 (ghc) of user 1000 dumped core. Jan 17 15:42:23 abanc kernel: ghc_worker[14939]: unhandled signal 11 at 0000000000000000 nip 00003fff8122b4f4 lr 00003fff81228774 code 30001 Jan 17 15:42:41 abanc systemd-coredump[15017]: Process 14820 (Setup) of user 1000 dumped core. }}} Trying to analyse one of the core file with gdb refer to SIGSEGV in stg_ap_0_fast as per extract below. I do not know how to continue investigation from there. {{{ + echo 'r -B/usr/lib64/ghc-8.0.1 ' + exec gdb -c /var/lib/systemd/coredump/core.ghc.1000.b44d99385b4c45eb840722189ffdf026.14822.1484667743000000 -x /tmp/gdbparms /usr/lib64/ghc-8.0.1/bin/ghc GNU gdb (GDB; openSUSE Tumbleweed) 7.11.1 ... Reading symbols from /usr/lib64/ghc-8.0.1/bin/ghc...Reading symbols from /usr/lib/debug/usr/lib64/ghc-8.0.1/bin/ghc.debug...done. done. [New LWP 14939] [New LWP 14861] [New LWP 14951] ... [New LWP 14932] [New LWP 14927] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/lib64/ghc-8.0.1/bin/ghc -B/usr/lib64/ghc-8.0.1 --make -fbuilding-cabal-pac'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00003fff8122b4f4 in stg_ap_0_fast () from /usr/lib64/ghc-8.0.1/bin/../rts/libHSrts_thr-ghc8.0.1.so [Current thread is 1 (Thread 0x3efdf27ff1a0 (LWP 14939))] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x3fffad6df1a0 (LWP 19906)] [New Thread 0x3fffacedf1a0 (LWP 19907)] [New Thread 0x3fffa7fff1a0 (LWP 19908)] ghc: no input files Usage: For basic information, try the `--help' option. [Thread 0x3fffa7fff1a0 (LWP 19908) exited] [Thread 0x3fffacedf1a0 (LWP 19907) exited] [Thread 0x3fffad6df1a0 (LWP 19906) exited] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:30:03 -0000 Subject: [GHC] #13148: Adding weak pointers to non-mutable unboxed values segfaults In-Reply-To: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> References: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> Message-ID: <059.b0d562e8a6b010c473a528be9ca1a657@haskell.org> #13148: Adding weak pointers to non-mutable unboxed values segfaults -------------------------------------+------------------------------------- Reporter: mboes | 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): I don't know exactly how `mkWeakNoFinalizer#` works but surely it can only possibly attach a finalizer to a value of ''boxed'' type, that is, a value that is stored as a closure on the Haskell heap. After all the meaning of a finalizer is that it's an action that runs when the object is no longer live after GC. `MutVar#` and `MVar#` are boxed (but unlifted) types, but `Addr#` is unboxed, really just a synonym for `Int#`. It doesn't make any more sense to attach a finalizer to `p#` than it does to attach one to `7#`. See https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects for the difference between unboxed and unlifted. The segfault happened because the weak finalizer code interpreted the bit pattern of `p#` as a pointer into the Haskell heap, while it was actually a pointer into the C heap (produced by `malloc`); and chaos ensued. (Based on this program snippet, it looks like you might just want `mallocForeignPtr`.) But morally the problem isn't really with C vs. Haskell heap but with trying to attach a finalizer to an unboxed value. The documentation you refer to is the documentation for the user-facing System.Mem.Weak module. We could add documentation to `mkWeakNoFinalizer#`, even though the primops are really only intended to be used to implement the base libraries. What would have been helpful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:42:58 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.449b47a663ee9e9616b080914ee7e31d@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What about `seq#` and `seq`? I'm not sure what it means for `seq` to be a "pseudoop", but `seq#` is a primop that takes a lifted argument and as far as I know it does evaluate that argument. Does it need `can_fail` too then? If there's a new invariant that primops that take lifted arguments must either not examine them or have some flag(s) set (such as `can_fail`), a reference to `Note [Primops with lifted arguments]` at the top of primops.pp would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:44:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:44:29 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.2dfddfaedb2fb85ed7d6b51b2447a805@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 dfeuer): * Attachment "prof-Store-Random-old" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:45:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:45:00 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.4448e84e3bee9f560b3cb412ba377dfb@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 dfeuer): * Attachment "prof-Store-Random-new" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:45:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:45:16 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.9997dd721e88eba8ae192d07209031f8@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 dfeuer): * Attachment "passes-Store-Random-old" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:45:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:45:30 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.2625e9e6ba53ece968d0f166c8063390@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 dfeuer): * Attachment "passes-Store-Random-new" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:45:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:45:45 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.e7af77d638d4c264bba25231e1281ce0@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 dfeuer): * Attachment "passes-Store-Tuples-old" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:45:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:45:59 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.0ebdb87107a1c31f98daf76fb3996d32@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 dfeuer): * Attachment "passes-Store-Tuples-new" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:46:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:46:11 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.36a6aea81b00338fd378b855fb059c30@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 dfeuer): * Attachment "prof-Store-Tuples-old" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:46:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:46: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.9c8aeca2ba72bdf80fdc533a689ebeaa@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 dfeuer): * Attachment "passes-Store-Tuples-new.2" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:46:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:46:47 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.142b312e5d256a8aca6edbb2faeedac5@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 dfeuer): * Attachment "prof-Store-Tuples-new" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:49:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:49:26 -0000 Subject: [GHC] #13059: High memory usage during compilation In-Reply-To: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> References: <049.ca0b5011a23d544f2c8147b153a2791e@haskell.org> Message-ID: <064.b9d8e618083f813b6b33bcd3dee58d0d@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've attached `-dshow-passes` and `-s` profiles for both the tuples and "random" files. It looks like there's practically no difference in passes between old and new tuples, but there's a good bit more allocation. Differences are much more substantial in the random one, with code size going up quite a lot right after float out and the profile showing considerably higher residency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:51:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:51:47 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.e4c78ceab9fa2a80bfb8d58e3da22ef4@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I imagine `seq#` is already marked as having side effects, which should also block float-out. I haven't checked though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:57:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:57:54 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.64ce40e788375b879d4ab0c974f0b4d1@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The fact that type application "telescopes" are normally only applied to single identifiers also helps my brain gloss over the parsing/precedence irregularities here. It's easy enough to read `+ @Int` as a unit. I know the manual says you can write things like `f x @Bool` meaning `(f x) @Bool` if `f` has a suitable type, though I wonder if there are any real uses for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 13:59:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 13:59:48 -0000 Subject: [GHC] #13107: Negative literal equal to minBound gives a spurious warning In-Reply-To: <044.def8d2f70cdee29238a18619ccf0af74@haskell.org> References: <044.def8d2f70cdee29238a18619ccf0af74@haskell.org> Message-ID: <059.06814654a367a8634835524556c8383a@haskell.org> #13107: Negative literal equal to minBound gives a spurious warning -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: I don't see the problem here, although the warning requires careful reading. `-128` is the application of unary minus to the literal `128`. The literal `128` that you wrote does indeed lie outside of the `Int8` range as the warning states. And the warning even suggested turning on `NegativeLiterals`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 14:26:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 14:26:22 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.f2d7ff681700d93ffd9ba777b9b314e6@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Actually, I'm wrong. I don't know what the deal is with `seq#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 15:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 15:24:14 -0000 Subject: [GHC] #13148: Adding weak pointers to non-mutable unboxed values segfaults In-Reply-To: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> References: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> Message-ID: <059.c9800b655c3e818eccb2780f39be5fde@haskell.org> #13148: Adding weak pointers to non-mutable unboxed values segfaults -------------------------------------+------------------------------------- Reporter: mboes | 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 mboes): OK that makes sense. I was surprised that things worked with `MutVar#` because I assumed it was also unboxed, but I see now that's not the case. The types in `System.Mem.Weak` already preclude creating a weak pointer to an unboxed value. But that of `mkWeakNoFinalizer#` is not precise enough to rule that out. Is the rule that the first argument to this function is valid iff it is of unlifted (primitive) type? If so, I think it would be useful to document that there. This exploration arose from the need to retrofit a single finalizer to a codebase that makes extensive use of `Ptr` without having to switch to `ForeignPtr` everywhere. The latter being more inconvenient, since it can't appear in the type signature of foreign imports. I assume attaching a finalizer to a `Ptr` runs the risk that the finalizer might fire too early. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 15:36:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 15:36:41 -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.6758f78a9fd0cc39da149ef382b99fe6@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 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! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 16:05:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 16:05:52 -0000 Subject: [GHC] #13148: Adding weak pointers to non-mutable unboxed values segfaults In-Reply-To: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> References: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> Message-ID: <059.85821f50a2661e45d974d4e4fccf96ab@haskell.org> #13148: Adding weak pointers to non-mutable unboxed values segfaults -------------------------------------+------------------------------------- Reporter: mboes | 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): A `Ptr` is a wrapper around `Addr#` in the same way that `Int` is a wrapper around `Int#`. The `Ptr` itself has no meaningful lifetime or identity (unlike the underlying memory pointed to by the pointer). So yes, attaching a finalizer to a `Ptr` will not be useful. Using `Ptr` is entirely equivalent to programming in C with manual memory management; the Haskell GC can't help you here. `Ptr` really might just as well be `Int` as far as Haskell is concerned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 17:16:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 17:16:28 -0000 Subject: [GHC] #13148: Adding weak pointers to non-mutable unboxed values segfaults In-Reply-To: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> References: <044.326fe50a11e8f70725ff47cdad1e7ba8@haskell.org> Message-ID: <059.334b584955c07139dd8fb603ab68a834@haskell.org> #13148: Adding weak pointers to non-mutable unboxed values segfaults -------------------------------------+------------------------------------- Reporter: mboes | 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): > Is the rule that the first argument to this function is valid iff it is of unlifted (primitive) type? If so, I think it would be useful to document that there. I think the rule is probably that the argument must be of boxed type. Surely it must be necessary; not sure whether it is also sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 17:53:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 17:53:47 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.bc56bcbe2c354da78b4e951acfa6880a@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:18 rwbarton]: > I know the manual says you can write things like `f x @Bool` meaning `(f x) @Bool` if `f` has a suitable type, though I wonder if there are any real uses for that. One plausible-sounding scenario is in specializing a polymorphic function accessed by a record selector: {{{#!hs data Mon'd m = MkMon'd { ret'rn :: forall a. a -> m a } f :: Mon'd m -> ... f dict ... = ... ret'rn dict @Int ... }}} But, yes, frequently the function applied to type parameters is just an identifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 18:20:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 18:20:07 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.6edfdfa3e7a2bcb699571355dd0ce05b@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Agh, I just saw that my test case was almost a word-for-word copy of Ryan's. I'll leave it in place to preserve history. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 20:14:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 20:14:44 -0000 Subject: [GHC] #13149: Giving Backpack a Promotion Message-ID: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> #13149: Giving Backpack a Promotion -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Research needed 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: -------------------------------------+------------------------------------- This ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done on this in the near future, but I'd like to keep track of these breadcrumbs. * We currently assume that it is impossible for a typechecked-only module (that is, one with no Core unfoldings) to refer to a DFun or a coercion axiom. In the absence of promotion, I'm pretty sure this is the case, since there is no way to refer to a term from a type (DFun), and coercions do not ordinarily occur at the type level. With promotion, the situation is murkier. If I understand correctly, `CoercionTy` embeds coercions in types, so in principle it should be possible to end up with a type that refers to a coercion explicitly, when you promote a GADT. However, I haven't tried too hard to find an example source program where this happens. goldfire, perhaps you would know? I can probably turn it into a panic with GHC HEAD. * (Put more problems here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 20:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 20:42:25 -0000 Subject: [GHC] #13150: unknown warning is not reported by GHC Message-ID: <049.672ae1b4361f2e5aa46b2a80fb5e7e8f@haskell.org> #13150: unknown warning is not reported by GHC -------------------------------------+------------------------------------- Reporter: jonaprieto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documented and official flag for the warning when a module, function or type with a WARNING or DEPRECATED pragma is used is `-fwarn-warnings- deprecations`. (See for instance https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/options- sanity.html). If the goal is turn off the warning I use `-fno-warn- warnings-deprecations` flag. By default `-fwarn-warnings-deprecations` on. In the next example shows a warning by using the flag mention above. {{{ $ cat Foo.hs {-# OPTIONS_GHC -fwarn-warnings-deprecations #-} import Data.Version (Version(Version, versionBranch, versionTags)) main :: IO () main = do let v = Version { versionBranch = [1,0,0] , versionTags = ["beta"] } return () }}} and GHC outputs: {{{ $ ghc Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Foo.hs:9:11: warning: [-Wdeprecations] In the use of ‘versionTags’ (imported from Data.Version): Deprecated: "See GHC ticket #2496" Linking Foo ... }}} The first unexcepted behavior is the warning message showed above. Following the convention the warning message should be: {{{ Foo.hs:9:11: warning: [-Wwarnings-deprecations] }}} The second unexcepted behavior happened when I used a pragma to silenced the warning `warnings-deprecations`, I committed the mistake to misspelled it, but surprisingly GHC didn't complaint about the unknown pragma, it seems treated again like a synonymous of `-fno-warn-warnings- deprecations` in this case. {{{ {-# OPTIONS_GHC -fno-warn-deprecations #-} import Data.Version (Version(Version, versionBranch, versionTags)) main :: IO () main = do let v = Version { versionBranch = [1,0,0] , versionTags = ["beta"] } return () }}} Searching a little, I found it is not documented the flag -Wdeprecations in recent versions of GHC ( I tested with 7.8.2 too) but it does for instance available in GHC 6.3.0 (See https://manned.org/ghc-cvs/42a4c961) but it actually continues appearing in the source code of the recent GHC. See https://github.com/mlen/ghc/search?utf8=%E2%9C%93&q=deprecations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 21:33:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 21:33:34 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.d9c4c377ed55b0a618e9e32548d2bee0@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think thomie's version could be made a bit more intuitive using something like {{{ runghc [runghc flags] module|filename [--ghc-flags [GHC flags]] [-- [program args]] }}} For example {{{ runghc Foo --ghc-flags -Wall -ddump-simpl -- -hi --bi }}} Like thomie's version, this requires the GHC flags to come after all runghc options and the module name, but it marks them out explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 21:55:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 21:55:47 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.ed3bb76a95bac458cc91a90437b46614@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think this issue should probably be addressed using the new GHC proposal process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 22:39:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 22:39:54 -0000 Subject: [GHC] #13136: Foreign.C.Types does not have a CBool type In-Reply-To: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> References: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> Message-ID: <062.cdcd9e4d692d3a334e72f5c77415abb6@haskell.org> #13136: Foreign.C.Types does not have a CBool type -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 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: | Differential Rev(s): Phab:D2982 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0d769d5b96232ee0fe5a44f2ce5717bdb0e7eaa3/ghc" 0d769d5b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d769d5b96232ee0fe5a44f2ce5717bdb0e7eaa3" Add CBool to Foreign.C.Types This adds a `CBool` type wrapping C99's `bool`, i.e., an `unsigned char`. Fixes #13136. Test Plan: ./validate on Tier-1 platforms Reviewers: austin, hvr, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2982 GHC Trac Issues: #13136 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 22:39:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 22:39:54 -0000 Subject: [GHC] #11789: Flag suggestion does not always work In-Reply-To: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> References: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> Message-ID: <061.549c21454159256a9441bc9270bf0161@haskell.org> #11789: Flag suggestion does not always work -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | 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: #11429 | Differential Rev(s): Phab:D2978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"181688abae5c0b32237a5bd783dfc9667641cce2/ghc" 181688a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="181688abae5c0b32237a5bd783dfc9667641cce2" Improve suggestion for misspelled flag including '=' (fixes #11789) Test Plan: Added 2 test cases, verified that ghc can suggest in the following cases: - for misspelled flag containing '=', ghc suggests flags that doesn't contain '=' - for misspelled flag containing '=', ghc suggests flags that contains '=' Reviewers: austin, dfeuer, bgamari Reviewed By: dfeuer, bgamari Subscribers: dfeuer, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2978 GHC Trac Issues: #11789 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 18 22:39:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jan 2017 22:39:54 -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.dca08d0ba9d89cc818f5b901884ffccc@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 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 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"38374caa9d6e1373d1b9d335d0f99f3664931fd9/ghc" 38374caa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38374caa9d6e1373d1b9d335d0f99f3664931fd9" Fix get_op in the case of an unambiguous record selector (#13132) Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2985 GHC Trac Issues: #13132 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 00:08:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 00:08:00 -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.6a855a1d83699039be0c4158d4940d6b@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: new 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 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Leaving this open until we also fix the ambiguous case described above. Adam, do you suppose you could have a look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 00:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 00:08:27 -0000 Subject: [GHC] #13136: Foreign.C.Types does not have a CBool type In-Reply-To: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> References: <047.152ac876e5c1feec4884fbe39dfcd745@haskell.org> Message-ID: <062.a77bce6f1dadf41e518f65ddd35000c8@haskell.org> #13136: Foreign.C.Types does not have a CBool type -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: libraries/base | 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:D2982 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 00:08:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 00:08:53 -0000 Subject: [GHC] #11789: Flag suggestion does not always work In-Reply-To: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> References: <046.8956aee4cb2b3d361b8607128f32a5f4@haskell.org> Message-ID: <061.b779d5854816f601d6307477a01c49ec@haskell.org> #11789: Flag suggestion does not always work -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Driver | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11429 | Differential Rev(s): Phab:D2978 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 Jan 19 00:58:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 00:58:45 -0000 Subject: [GHC] #13151: Make all never-exported IfaceDecls implicit Message-ID: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> #13151: Make all never-exported IfaceDecls implicit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Consider the representation of an instance in an interface file. It is always associated with a DFun, but the DFun is stored as a separate IfaceDecl. You might wonder if it's possible for an IfaceClsInst to refer to an externally defined DFun, or if it's possible to have a DFun but no IfaceClsInst associated with it. The current ClsInst representation won't tell you, but in fact, it's impossible. For example, DFuns are manually added to the type environment by TidyPgm, which literally goes through the list of ClsInsts to pull out the set of DFunIds which need to be added to the TypeEnv. This all seems horribly indirect. Why not just *embed* the IfaceDecl describing the DFun inside IfaceClsInst, and treat the DFun as an "implicit TyThing"? This makes it clear that the instance declaration canonically defines the DFun. To do this, we have to expand our idea of implicit TyThings; at the moment, only a TyThing can be associated with implicit TyThings. With this change, instances and family instances can also be associated with implicit TyThings. But this doesn't seem like too much. Why does this matter? I was cleaning up some code in Backpack, and I noticed that I had written some very complicated things to handle DFuns and coercion axioms, because they were indirected through a Name, even though morally they should have been "implicit"-like things. The proposed refactor here would solve this correctness problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 02:56:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 02:56:12 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.613f91bcbd34a7d9ca9776b94ba8181a@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I find it rather unintuitive to embed the ghc flags between the program name and the program flags. It is simpler to say and understand: {{{ runghc [flags] [filename [program args]] }}} ghc options becomes just one of the flags which is easier to understand (IMO). I agree that using one "--ghc-options" for all ghc flags is more convenient. If that is acceptable, I can try to find existing code to be able to do that (i.e. handle the escaping). I am fine with the proposal process but I won't be able to drive that myself, though I can contribute to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 03:04:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 03:04:32 -0000 Subject: [GHC] #13149: Giving Backpack a Promotion In-Reply-To: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> References: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> Message-ID: <060.fdb371dc98a896566ac07edafc21f034@haskell.org> #13149: Giving Backpack a Promotion -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, with `-XTypeInType`, coercions appear in types. For example: {{{ type family F a where F Bool = Type foo :: forall (a :: F Bool). a -> a foo x = x }}} (Panics in GHC 8.0.1, but works in HEAD.) The type of `foo` will contain a reference to a coercion axiom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 04:10:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 04:10:22 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.d0ccef9318c869239fe78048e8c2c5bb@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That proposal sounds reasonable to me. Care to submit a patch that fixes this infelicity? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 04:16:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 04:16:24 -0000 Subject: [GHC] #13146: Doc for RealWorld refers to non-existent "ptrArg" In-Reply-To: <051.16114a56d2c2d800656a0dcdf2ae3831@haskell.org> References: <051.16114a56d2c2d800656a0dcdf2ae3831@haskell.org> Message-ID: <066.75cf49af35dfd5ba502135d16218ec81@haskell.org> #13146: Doc for RealWorld refers to non-existent "ptrArg" -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonmar (added) Comment: Huh, that's quite an unusual description. A quick search reveals that Simon Marlow added this description to `RealWorld` all the way back in 2007: http://git.haskell.org/ghc.git/blobdiff/e07e2550074ddc7d96e2092e56add418403bd29a..604539cd8f4577198535d30d61e3c9e4f20e2745:/compiler/prelude/primops.txt.pp Simon, do you recall what you meant by "`ptrArg`"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 04:22:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 04:22:02 -0000 Subject: [GHC] #13147: Formatting is broken in Exceptions section of GHC.Prim haddock In-Reply-To: <051.0397004541ccc405db287acf386a2c03@haskell.org> References: <051.0397004541ccc405db287acf386a2c03@haskell.org> Message-ID: <066.bffbb3f75868e48387d513bd4005d568@haskell.org> #13147: Formatting is broken in Exceptions section of GHC.Prim haddock -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Yikes. Further complicating this is that the Haddocks for `GHC.Prim` aren't written in a Haskell file, but rather a text file `compiler/prelude/primops.txt.pp` that is compiled to an `.hs` file. I suspect that this process causes the Note (which should rightly be a comment not visible to Haddock readers) to be misinterpreted as a section description, see http://git.haskell.org/ghc.git/blob/38374caa9d6e1373d1b9d335d0f99f3664931fd9:/compiler/prelude/primops.txt.pp#l1944 . A simple workaround would be to move the Note so that it isn't immediately beneath a `section`, //à la// `Note [dataToTag#]` (see http://git.haskell.org/ghc.git/blob/38374caa9d6e1373d1b9d335d0f99f3664931fd9:/compiler/prelude/primops.txt.pp#l2602). Chris, would you care to take this up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 04:49:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 04:49:29 -0000 Subject: [GHC] #13149: Giving Backpack a Promotion In-Reply-To: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> References: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> Message-ID: <060.2890780d4e3b04871d9c2de2b981394d@haskell.org> #13149: Giving Backpack a Promotion -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | 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: | -------------------------------------+------------------------------------- @@ -13,6 +13,20 @@ - With promotion, the situation is murkier. If I understand correctly, - `CoercionTy` embeds coercions in types, so in principle it should be - possible to end up with a type that refers to a coercion explicitly, when - you promote a GADT. However, I haven't tried too hard to find an example - source program where this happens. goldfire, perhaps you would know? I can - probably turn it into a panic with GHC HEAD. + With promotion, this is not true: + + {{{ + {-# LANGUAGE TypeFamilies #-} + {-# LANGUAGE Rank2Types #-} + {-# LANGUAGE TypeInType #-} + unit p where + signature A where + import GHC.Types + type family F a where + F Bool = Type + module B where + import A + foo :: forall (a :: F Bool). a -> a + foo x = x + unit q where + dependency p[A=] + module C where + import B + }}} New description: This ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done on this in the near future, but I'd like to keep track of these breadcrumbs. * We currently assume that it is impossible for a typechecked-only module (that is, one with no Core unfoldings) to refer to a DFun or a coercion axiom. In the absence of promotion, I'm pretty sure this is the case, since there is no way to refer to a term from a type (DFun), and coercions do not ordinarily occur at the type level. With promotion, this is not true: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} {-# LANGUAGE TypeInType #-} unit p where signature A where import GHC.Types type family F a where F Bool = Type module B where import A foo :: forall (a :: F Bool). a -> a foo x = x unit q where dependency p[A=] module C where import B }}} * (Put more problems here) -- Comment (by ezyang): Thanks! It was an easy matter to turn it into a Backpack failure; I've added it to the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 04:50:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 04:50:27 -0000 Subject: [GHC] #13149: Giving Backpack a Promotion In-Reply-To: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> References: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> Message-ID: <060.4a4f660a1fbf2c25e54d88c2a6dae614@haskell.org> #13149: Giving Backpack a Promotion -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -34,0 +34,8 @@ + This will fail in a puzzling way: + + {{{ + : error: + The identifier D:R:F does not exist in the signature for + (Try adding it to the export list in that hsig file.) + }}} + New description: This ticket is tracking assumptions the current implementation of Backpack makes about terms and types, which may be violated when more and more term-level things start being lifted into the type level. I don't expect any work to be done on this in the near future, but I'd like to keep track of these breadcrumbs. * We currently assume that it is impossible for a typechecked-only module (that is, one with no Core unfoldings) to refer to a DFun or a coercion axiom. In the absence of promotion, I'm pretty sure this is the case, since there is no way to refer to a term from a type (DFun), and coercions do not ordinarily occur at the type level. With promotion, this is not true: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} {-# LANGUAGE TypeInType #-} unit p where signature A where import GHC.Types type family F a where F Bool = Type module B where import A foo :: forall (a :: F Bool). a -> a foo x = x unit q where dependency p[A=] module C where import B }}} This will fail in a puzzling way: {{{ : error: The identifier D:R:F does not exist in the signature for (Try adding it to the export list in that hsig file.) }}} * (Put more problems here) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 13:39:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 13:39:14 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.7d2e22ce4eaa791965591a9cbe7f335a@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Yuras): This terminology comes from [https://www.haskell.org/onlinereport/haskell2010/haskellch7.html#x14-1420007 Haskell Report], so IMO the proposal should go through the [https://prime.haskell.org/wiki/Committee language committee]. (Haskell is not math, so there is nothing wrong if haskell uses its own definitions) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 14:24:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 14:24:06 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.bf38fe8706b62a8db9effa3d8e0bf652@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): Phab:D2992 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D2992 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 14:24:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 14:24:52 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.078c091b657a9739ded291d9e6f94c15@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- Reporter: rwbarton | 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: rwbarton => Comment: Phab:D2990 has the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:37:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:37:46 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.9676a9301eb8684f4abf3b2d33e8f622@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:37:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:37:46 -0000 Subject: [GHC] #12973: No levity-polymorphic arguments In-Reply-To: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> References: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> Message-ID: <062.56f433db8bcc18db9ccc4882d030b88a@haskell.org> #12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:37:47 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.bf54c704e5749ce3a2a2858a45f81265@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:37:47 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.bca65c2e5bc521d2bff2e445e58aabe3@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:37:47 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.b0f235a6937964aaf32437570c936235@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism 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 Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:37:47 -0000 Subject: [GHC] #12987: Core lint error with levity polymorphism In-Reply-To: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> References: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> Message-ID: <066.38a6468ed0045a4df5071452028326cd@haskell.org> #12987: Core lint error with levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:39:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:39:04 -0000 Subject: [GHC] #12973: No levity-polymorphic arguments In-Reply-To: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> References: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> Message-ID: <062.27ee82f44e6fb268d59c557abf3da242@haskell.org> #12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12973 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_fail/T12973 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:39:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:39:58 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.62a2726f8b6ad83e9191da1f2bbea81c@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/StrictBinds Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/StrictBinds * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:40:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:40:40 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.920996df2090f0267d72994851801ce4@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): NB: The above commit does ''not'' fix this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:41:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:41:10 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.556aaf634c87f8ea1057d6595d3b35e1@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11736 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T11736 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:41:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:41:45 -0000 Subject: [GHC] #12987: Core lint error with levity polymorphism In-Reply-To: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> References: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> Message-ID: <066.39ce00e3919b9a880bc08c8adabe22b8@haskell.org> #12987: Core lint error with levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12987 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_compile/T12987 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:42:58 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.5ef4ec36f4dac821dc581f437e0606b0@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T12809 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_run/T12809 * resolution: => fixed Comment: No more lies! Only truthiness from now on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 15:45:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 15:45:32 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.c1eb9e510fb9cbca6194aceb5f2b547c@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T12809 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, goldfire! I'll try to revisit the fixes for #11723, #11724, and #11509 at some point. I believe they all put in checks that forbade the use of `UnboxedTupleRep` and `UnboxedSumRep` in deriving because it was assuming the inadequacies of the old system for levity polymorphism, but now that's it's overhauls, I don't believe those checks are required anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 17:46:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 17:46:54 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.4b9ee9537d114eb43b9c1d1588b9f271@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris-martin): I'm not concerned with the math so much as making sure that Haskell does actually use its own definitions. To the best of my understanding, a function in Haskell is defined as a value of the type `a -> b` for some `a` and `b`. Is that disputed? Looking at the Haskell Report a bit further, it seems like "function" is pretty inconsistently used, so I agree the fix for this problem (''if'' it is in fact a problem and not just my misunderstanding) should start there at the root. Any idea where is the best place to start that conversation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 17:48:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 17:48:41 -0000 Subject: [GHC] #13152: Provide a mechanism to notify build system when .hi file is ready Message-ID: <047.38e2134538b3404b1f045ea57eb9cc2e@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Driver | 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: -------------------------------------+------------------------------------- In one-shot mode GHC typically finishes writing the interface file around halfway through compilation. A dependent module (if it doesn't use Template Haskell) only needs the interface file to start building. If we could start building a module as soon as all its dependencies' interface files are ready, we would cut the critical path by about a factor of 2; and parallelism in the GHC build tree is currently low enough that this should give significantly lower build times even on only modestly parallel systems. The first obstruction to doing this is that there isn't a good way to know when the interface file becomes ready. I propose the following simple and flexible mechanism: * Add a GHC command-line argument `-finterface-file-finished=N,F,str`. When GHC has finished writing the interface file it uses the `send` system call to send the string `str` to file descriptor `N` using flags `F`. The build system might then invoke GHC with file descriptor `N` open to a UNIX datagram socket, for example, and generate a unique `str` for each interface file dependency. Alternative suggestions are more than welcome. I tentatively milestoned this for 8.2 since it would be nice to have this available in the bootstrapping compiler when we switch to Hadrian, and the GHC-side implementation should be simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 17:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 17:52:22 -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.f904f4662f4b132cc88cc960efc2758b@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by ezyang): If GHC wrote out the interface file atomically, could this be implemented just by watching the output files of a GHC invocation? (Maybe not on Windows?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 18:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 18:13:08 -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.6fa4d3fe7b14659b204e318e2fd53bff@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not sure. What if the interface file already existed, and either (1) we checked that we don't need to recompile (in which we currently don't touch the interface file at all), or (2) we do need to recompile and write out a new interface file? Programming with inotify can be fiddly (for example, the man page says that it is possible for events to be lost), and I don't know whether we could reliably distinguish a new/unchanged-but-confirmed-valid interface file from a stale one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 18:23:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 18:23:47 -0000 Subject: [GHC] #13145: Documentation shouldn't call things functions that aren't functions In-Reply-To: <051.129037e11cb5648c9e72e783766a6946@haskell.org> References: <051.129037e11cb5648c9e72e783766a6946@haskell.org> Message-ID: <066.76efaf600060d05670846add1ff65b1a@haskell.org> #13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Yuras): You can go ahead and submit a patch because my opinion is just an opinion. Or you can drop a message to [https://mail.haskell.org/cgi- bin/mailman/listinfo/haskell-prime haskell-prime] mailing list and see what people think about that. I think your definition is a bit naive because the same (polymorphic) value will or will not be a function depending on a context: {{{ Prelude> let func = pure 5 :: Applicative m => m Int Prelude> func 5 Prelude> func 12 5 Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 18:46:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 18:46:58 -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.80432d807669c98163f9139dff0bb511@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): It might not even be that hard to retrofit use of this feature into the existing build system, changing a rule like {{{ Foo.hi : Bar.hi Baz.hi ghc -c Foo.hs }}} to something like {{{ Foo.hi : Bar.hi Baz.hi ( ( ghc -c Foo.hs -finterface-file-finished=1,0,x ; \ buildserver finished Foo.o ) & ) | read -n 1 }}} and then for the `.o` files {{{ Foo.o : Foo.hi buildserver await Foo.o }}} Here `buildserver await` is a program that will block until the corresponding `buildserver finished` has been run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 18:58:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 18:58:38 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap Message-ID: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example, we define {{{#!hs instance Traversable ZipList where traverse f (ZipList xs) = ZipList <$> traverse f xs }}} If the list is very short, the extra `fmap` could be bad. We can fix this by inlining the inner `traverse`. However, I suspect a better approach would be to add a method to `Traversable`: {{{#!hs mapTraverse :: Applicative f => (t b -> r) -> (a -> f b) -> t a -> f r mapTraverse p f xs = p <$> traverse f xs }}} but I need to work through whether this is enough power to solve enough problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 19:11:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 19:11:48 -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.03c815e47d39a1a37807002ce642a9a7@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by niteria): This could be a great improvement for us. I will ask someone from the Buck team to take a look and see what kind of interface is most convenient for Buck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 21:22:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 21:22:20 -0000 Subject: [GHC] #13141: Don't check for Perl in ./configure when not splitting objects In-Reply-To: <047.a2722241ec56f4afc6afd14ced53477d@haskell.org> References: <047.a2722241ec56f4afc6afd14ced53477d@haskell.org> Message-ID: <062.80fe606898539534355cb4455503efe7@haskell.org> #13141: Don't check for Perl in ./configure when not splitting objects -------------------------------------+------------------------------------- Reporter: dobenour | Owner: dobenour Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 Demi Obenour ): In [changeset:"f07a6c17a3d6b32cc64b0b8318a05177fc098630/ghc" f07a6c17/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f07a6c17a3d6b32cc64b0b8318a05177fc098630" Don't error on missing Perl, just warn and disable object splitting. Summary: If Perl isn't needed, we don't need to error out. Since all Perl is used for is the splitter, we can just warn. Test Plan: GHC CI Reviewers: bgamari, hvr, austin Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2986 GHC Trac Issues: #13141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 21:32:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 21:32:14 -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.f139a666a0ee81a16b69592790ae8004@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by niteria): Sadly, the way things are structured right now in Buck it would be hard to take advantage of this. Buck has dependencies between commands, not between resources like Make does. That said it sounds like a big win for GHC with relatively low effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 22:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 22:22: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.0122cc59928dbf2db0a293aa7182856e@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hmm, I'm not familiar with Buck at all, but could you have an encoding with two commands per module, a command-to-build-`.hi` and a command-to- build-`.o`? In reality the command-to-build-`.hi` exits when ghc reports that it is done writing the `.hi` file but leaves ghc running in the background to finish building the `.o` file, and the command-to-build-`.o` just blocks until that finishes. The command-to-build-`.hi` only depends on other command-to-build-`.hi`s. That's how my `make` encoding really works anyways. Probably in a more sophisticated system you could express the idea of a command that produces two resources at different times directly. In fact, now that I look at my `make` example again, it seems one wouldn't even need a server to do the blocking; probably advisory file locks are enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 22:40:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 22:40:16 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.3455ced89524982a38f976406035c94d@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 RyanGlScott): Forgive my ignorance here, but how are you proposing to inline the inner `traverse`? In my mind, the only way I can see how you'd remove the `(<$>)` is if you had a special case for `ZipList []`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 22:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 22:43:23 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.9d80a13ca4816666cd3805105420aa16@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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): Replying to [comment:1 RyanGlScott]: > Forgive my ignorance here, but how are you proposing to inline the inner `traverse`? > > In my mind, the only way I can see how you'd remove the `(<$>)` is if you had a special case for `ZipList []`. You're confused about the definition. {{{#!hs newtype ZipList a = ZipList [a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 22:46:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 22:46:46 -0000 Subject: [GHC] #13151: Make all never-exported IfaceDecls implicit In-Reply-To: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> References: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> Message-ID: <060.f3c0ceab6133ceb36cc9ec1d257e2960@haskell.org> #13151: Make all never-exported IfaceDecls implicit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I like it the way it is. Here's why. Unfoldings for any old function might mention `$fEqList` the `DFun` for equality on lists. So there must be a top-level declaration for `$fEqList` in the interface file {{{ $fEqList :: forall a. Eq a -> Eq [a] -- ...together with arity, unfolding, strictness, whatever, just -- like any other Id... }}} or at least it is simple and convenient for that to be the case. It's particularly important that it has an unfolding;l this unfolding is always a `DFunUnfolding`. And once we have that, it seems simpler to refer to it from the instance decl rather than to duplicate it. I suppose you could put all this in the instance decl. But would need to define the top-level Id `$fEqList`. I have not yet grokked what's hard about the sataus quo. I'm not fundamentally against refactoring it though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 23:05:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 23:05:06 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.7fa2e42aaf8cae0062c7f8bd22f37789@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 RyanGlScott): But that's exactly the definition I had in mind. What I was alluding to is that you //could// remove the `(<$>)` is the case where the wrapped list is empty: {{{#!hs instance Traversable ZipList where traverse (ZipList []) = pure (ZipList []) }}} But what about this case? {{{#!hs traverse (ZipList (x:xs)) = ??? }}} I'm not seeing how you can fill in this case without needing to appeal to `fmap` or `(<*>)` at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 23:14:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 23:14:46 -0000 Subject: [GHC] #13151: Make all never-exported IfaceDecls implicit In-Reply-To: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> References: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> Message-ID: <060.b5ceed1f650c2ac50167d47f14c9a8d1@haskell.org> #13151: Make all never-exported IfaceDecls implicit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: | -------------------------------------+------------------------------------- Comment (by ezyang): > I suppose you could put all this in the instance decl. But would need to define the top-level Id $fEqList. Yes, that's the idea. The upshot is that IfaceClsInst, which doesn't itself define any TyThings, can define an implicit TyThing, `$fEqList`. I agree that we still need a `TyThing` for `$fEqList`, but there isn't any reason `$fEqList` needs to live in `mi_decls`; we just have to make sure it gets to the type environment in the end. Today, if I'm looking for an `OccName` from an interface, it may either be defined directly by an entry in `mi_decls`, or it is one of the implicit things defined by one of the `IfaceDecl`. My suggestion is to expand this to also include implicit things defined by `IfaceClsInst`s. > I have not yet grokked what's hard about the status quo. So, the problem is more pronounced for closed type families, so I'll do an example involving them. Suppose we have a signature that looks like this: {{{ signature A where type family F a where F a = Int }}} This will give us a type family, which refers to an axiom `TFCo:R:F` that specifies `F a ~ Int`. Furthermore, let's suppose that we're trying to match this against the following module: {{{ module A where type family F a where F a = Bool }}} When we typecheck the interface to make the TyThings for the type family we are going to compare, we need to need to resolve the Name `TFCo:R:F` from the hsig's interface to an actual Coercion. If we resolve `TFCo:R:F` to point to the *module*'s coercion, that's a disaster, because we never actually check that the top-level *coercions* match, we only check that the Coercion recorded in the type family (which we pointed at the module) matches. "Now," you might say, "why didn't you just have `TFCo:R:F` point to the hsig's version, then there's no problem." This is true, but in other cases, pointing to the module's versions of TyThings is very useful. Consider this other case: {{{ signature M where data T f :: T module M where type T = Int f :: Int }}} If the `T` in `f :: T` is not resolved to `type T = Int`, we will conclude that `f :: T` and `f :: Int` are incompatible, when they should be compatible! I'd quite like this to work: it's very important when implementing abstract data with type synonyms. The current implementation does a delicate tight-rope walk, of resolving names to the module version, except in the few cases where we need to resolve it to the hsig version. Highly delicate. Why does making the coercion *implicit* simplify things? With an implicit `TyThing`, we can avoid doing a lookup for the coercion at all; just use the implicit copy that was embedded. This means we sidestep the possible bug. We don't have to do this refactor: maybe the more complex interface typechecking for general users outweighs the simplification in the Backpack case. But I wanted to put this proposal out there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 23:25:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 23:25:22 -0000 Subject: [GHC] #13151: Make all never-exported IfaceDecls implicit In-Reply-To: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> References: <045.c81f61fb497e2d1d5d82b412cf3b002c@haskell.org> Message-ID: <060.d0ecb65c5f07724dc48ff0508c073ed5@haskell.org> #13151: Make all never-exported IfaceDecls implicit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > maybe the more complex interface typechecking for general users I don't think it'd be much more complex. If you want to pursue this, it's ok with me. We'll see if the code looks more horrible; it'll probably be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 19 23:26:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jan 2017 23:26:43 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.578eb4d84084b5234a23f9cfee5f2bc5@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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): We have (essentially) {{{#!hs instance Traversable [] where traverse f = foldr cons_f (pure []) where cons_f x = liftA2 (:) (f x) }}} Manually copying this idea into the `ZipList` instance (I guess it's more than inlining) gives {{{#!hs instance Traversable ZipList where traverse f = foldr cons_f (pure (ZipList [])) .# getZipList where cons_f x = liftA2 (\x' ys' -> ZipList (x' : getZipList ys')) (f x) }}} The point is to fuse the final `ZipList <$>` into an operation that needs to happen anyway. `ZipList` is actually a terrible choice of example, because lists ''usually'' aren't short enough for this to matter much. But if you look at something like `First` or `Sum` it's more obviously silly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 00:00:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 00:00:58 -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.625f7f4efd95ffd6f5f4e963a9cd8c38@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here's how this could look with locks instead of a buildserver. The semantics of the lock file is that if you ran the action to build `Foo.hi` and you can take the lock on `Foo.o-lock`, then `Foo.o` is ready. {{{ Foo.hi : Bar.hi Baz.hi ( flock Foo.o-lock ghc -c Foo.hs -finterface-file-finished=1,0,x & ) \ | read -n 1 Foo.o : Foo.hi flock Foo.o-lock true }}} Ideally we'd also propagate the exit status of `ghc` to the rule for `Foo.o`, and clean up the lock files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 03:38:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 03:38:31 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.025c0d2edbc32fae7f66e430c6467ada@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 RyanGlScott): Ah, I see what you're getting at now. It's quite unfortunate that we have to go through such contortions to make applying the newtype constructor zero-cost. We certainly could change the `Traversable ZipList` implementation to what you suggest to avoid this quandary, but there's no getting around the fact that it's a hack. One thing I've contemplated for a while is adding an `unsafenewtype` deriving strategy that implements what Richard suggests in https://ghc.haskell.org/trac/ghc/ticket/9123#comment:27. That is, if you wrote: {{{#!hs {-# LANGUAGE DerivingStrategies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype ZipList a = ZipList [a] deriving newtype (Functor, Foldable) deriving unsafenewtype (Traversable) }}} Then the derived `Traversable ZipList` instance would be: {{{#!hs instance Traversable ZipList where traverse :: forall f a b. Applicative f => (a -> f b) -> ZipList a -> f (ZipList b) traverse = unsafeCoerce (traverse :: (a -> f b) -> [a] -> f [b]) }}} Granted, this is a separate hack to get around the fact that we don't have higher-kinded roles yet, but it's (IMO) much nicer to use than having to manually inline the definition of `traverse` like you demonstrated above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 04:21:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 04:21:30 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances Message-ID: <050.313c7572181a73220f1b076de5274da4@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: 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: -------------------------------------+------------------------------------- Note that these are accepted: {{{#!hs class Foo (a :: TYPE ('TupleRep '[])) instance Foo (a :: TYPE ('TupleRep '[])) instance Foo (##) }}} But if you try to write these same instances using `DeriveAnyClass` and `StandaloneDeriving`, they'll be rejected for no good reason: {{{#!hs deriving instance Foo (a :: TYPE ('TupleRep '[])) {- • Can't make a derived instance of ‘Foo a’: The last argument of the instance must be a data or newtype application -} deriving instance Foo (##) {- • Can't make a derived instance of ‘Foo (# #)’: The last argument of the instance cannot be an unboxed tuple -} }}} The latter error is a vestige of #12512, and should be easy enough to rectify. The former error is a bit tricker to fix, since much of the code in `TcDeriv`/`TcDerivInfer` assumes that the type to which the class is applied to in the instead head is a datatype or newtype `TyCon`. It's apparent that this doesn't hold true in the presence of `DeriveAnyClass`, however, so that code should be refactored to reflect this. For practical reasons, however, it might be best to wait until after #12144 is fixed to tackle this one, since that splits out some logic in `TcDerivInfer` for `DeriveAnyClass` so as to make it no longer rely on the aforementioned `TyCon` invariant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 04:25:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 04:25:00 -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.4d2f0f71024393e6181ac0a5e74908c1@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: 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): * keywords: => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 04:27:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 04:27:38 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.b7c01e899b62dcd3063db99cc966d0ba@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): About two weeks have passed since this was first proposed, and there doesn't seem to be any definite consensus. In fact, I'm not sure if you even want this to be implemented anymore, since you seem reticent to give up the ability to define custom `Generic` instances. If you do wish to pursue this further, I'd highly recommend creating a GHC proposal for it, since this seems to be a topic of contention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 04:31:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 04:31:14 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.a889b328a2f463db322502d67fc9266d@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 RyanGlScott]: > About two weeks have passed since this was first proposed, and there doesn't seem to be any definite consensus. In fact, I'm not sure if you even want this to be implemented anymore, since you seem reticent to give up the ability to define custom `Generic` instances. If you do wish to pursue this further, I'd highly recommend creating a GHC proposal for it, since this seems to be a topic of contention. I am of two minds. I see very good reasons to make this change, and I see very good reasons to be wary of it. I'm not the main person pushing for it; I'm just the one who wrote it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 05:20:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 05:20:13 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.95b9ceb9154e50636a2cf7acc6d89b58@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 nomeata): The `fmap` in {{{ instance Traversable ZipList where traverse f (ZipList xs) = ZipList <$> traverse f xs }}} is not polymorphic, but rather a concret one (the one from `Functor []`), right? I would expect that to be resolved to actual `map`, for which we have a `map/coerce` rule, which should optimize the whole `ZipLib <$>` stuff away. Did you check the core if there is really an `fmap` or `map` left? If so, then the rules don't work as expected, and that is a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 08:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 08:39:23 -0000 Subject: [GHC] #13065: Prohibit user-defined Generic and Generic1 instances In-Reply-To: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> References: <045.b4dc31d89fd7531070ea7e6822059621@haskell.org> Message-ID: <060.41798991c9b03562e5115be9590166c2@haskell.org> #13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, well, since there are good reasons to be wary let's not rush to make a change. The status quo is by definition cheaper. While the idea was ''precipitated'' by the question of tuples (and the overhead of reading interface files etc), it should not be ''driven'' by that. Maybe there's another way to address the perf question. It was only that, if there was a quick consensus, it seemed like an easy way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 10:58:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 10:58:02 -0000 Subject: [GHC] #13155: exprIsExpandable bug Message-ID: <046.ba7c808d6e462cf5fe9d4c7979057bdc@haskell.org> #13155: exprIsExpandable bug -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider this program, derived from T5623 (c.f. #5623) {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -funfolding-use-threshold=10 #-} module T5623 where import GHC.Ptr import GHC.Prim import GHC.Exts foo :: Ptr Float -> State# RealWorld -> (# State# RealWorld, Float #) -- foo p = liftM2 (+) (peekElemOff q 0) (peekElemOff q 1) foo p s = case q :: Ptr Float of { Ptr a1 -> case readFloatOffAddr# a1 0# s of { (# s1, f1 #) -> case q :: Ptr Float of { Ptr a2 -> case readFloatOffAddr# a2 1# s of { (# s2, f2 #) -> (# s2, F# (plusFloat# f1 f2) #) }}}} where q :: Ptr a -- Polymorphic q = p `plusPtr` 4 }}} The `-funfolding-use-threshold=10` is important because it makes the worker/wrapper pass do a w/w split for `foo`. (Otherwise it's too small for w/w.) The optimised core looks like {{{ foo = \ (w_s2TO :: Ptr Float) (w1_s2TP :: State# RealWorld) -> case w_s2TO of { Ptr ww1_s2TS -> case readFloatOffAddr# @ RealWorld (plusAddr# ww1_s2TS 4#) 0# w1_s2TP of { (# ipv_s2ST, ipv1_s2SU #) -> case readFloatOffAddr# @ RealWorld (plusAddr# ww1_s2TS 4#) 1# w1_s2TP of { (# ipv2_s2SY, ipv3_s2SZ #) -> (# ipv2_s2SY, GHC.Types.F# (plusFloat# ipv1_s2SU ipv3_s2SZ) #) } } } }}} Yikes! Look at that duplicated `plusAddr#`! It turned out to be a hard-to-trigger bug in `exprIsExpandable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 11:31:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 11:31:14 -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.9605ad4d8499346cfc5c1aac2ce978c4@haskell.org> #13152: Provide a mechanism to notify build system when .hi file is ready -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by niteria): You're right, I believe it could work with the encoding you proposed. The tricky bit would be ensuring that the processes, locks and handles don't get leaked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 11:37:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 11:37:50 -0000 Subject: [GHC] #13156: CSE missing an easy case Message-ID: <046.e75b8366dc8aaa94cd7e951008b64c50@haskell.org> #13156: CSE missing an easy case -------------------------------------+------------------------------------- Reporter: simonpj | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this Core: {{{ case f @Int of { r1 -> case f @Int of { r2 -> ... }}} There is an easy common sub-expression to be had here, which would allow to eliminate a case expression, but CSE didn't spot it in GHC 8. Easy to fix. Here's an example that shows it {{{ module Bug where f g x = let r :: [a] -> [a] r = case g x of True -> reverse . reverse False -> reverse in r `seq` r `seq` True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 11:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 11:53:42 -0000 Subject: [GHC] #13157: Opportunity to improve case-of-case Message-ID: <046.6083067245a0621fcdfe440b63017d34@haskell.org> #13157: Opportunity to improve case-of-case -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider this code {{{ f g x = (case g x of True -> not False -> id) `seq` True }}} With GHC 8 (and -O) we get this Core {{{ f = \ (@ t_a1rk) (g_aqD :: t -> Bool) (x_aqE :: t) -> case case g_aqD x_aqE of { False -> id @ Bool; True -> not } of { __DEFAULT -> GHC.Types.True } }}} This is obviously bad. The reasoning is in the long, complicated `Note [Single-alternative cases]` in `Simplify.hs`. Happily with join points the entire Note becomes unnecessary; we can delete the special case that this Note describes, and the Note itself. Result: simpler compiler, and more optimal code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 11:53:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 11:53:55 -0000 Subject: [GHC] #13157: Opportunity to improve case-of-case In-Reply-To: <046.6083067245a0621fcdfe440b63017d34@haskell.org> References: <046.6083067245a0621fcdfe440b63017d34@haskell.org> Message-ID: <061.9cbe5a597de0ef77e8113e300a7e5572@haskell.org> #13157: Opportunity to improve case-of-case -------------------------------------+------------------------------------- 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): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 13:49:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 13:49:58 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.3600d2fbdbb4a665b12fb344142a0067@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 mpickering): I am very skeptical of adding all these special functions to type classes. Should we not improve the optimiser so that users can write normal idiomatic definitions without having to understand these intricacies? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 14:23:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 14:23:30 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.ee16007e0c312043a06b858b0020eed7@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's move this discussion about primops to #13027, which has more relevant discussion. I'll add a test for comment:10, which is indeed fixed by the patch in #13027. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 14:31:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 14:31:55 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.f8ca89e9f827dab2ed39ce4cae0d102d@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- Reporter: erikd | Owner: dfeuer 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: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => dfeuer Comment: * `reallyUnsafePtrEq#`: see comment:15 of #11444. Phab:D2987 does this (thank you David); but it has no test. (I'm not certain it neeeds one.) * `seq#` is mis-named. It should really be `evaluate#` because it's the primop version of `evaluate`: {{{ seq# :: a -> State# s -> (# State# s, a #) evaluate :: a -> IO a evaluate a = IO $ \s -> seq# a s -- NB. see #2273, #5129 }}} I don't think it needs any `can_fail` or `has_side_effects` attributes, because it is totally constrained by the threaded state. I wish I could be 100.00% certain, but that's how it looks to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 14:39:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 14:39:18 -0000 Subject: [GHC] #13155: exprIsExpandable bug In-Reply-To: <046.ba7c808d6e462cf5fe9d4c7979057bdc@haskell.org> References: <046.ba7c808d6e462cf5fe9d4c7979057bdc@haskell.org> Message-ID: <061.87efb097f248a2077a4c686ec5549d1f@haskell.org> #13155: exprIsExpandable bug -------------------------------------+------------------------------------- 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:"9be18ea4e5cbc53ce7769a30275332d68a4ab6b9/ghc" 9be18ea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9be18ea4e5cbc53ce7769a30275332d68a4ab6b9" Fix a nasty bug in exprIsExpandable This bug has been lurking for ages: Trac #13155 The important semantic change is to ensure that exprIsExpandable returns False for primop calls. Previously exprIsExpandable used exprIsCheap' which always used primOpIsCheap. I took the opportunity to combine the code for exprIsCheap' (two variants: exprIsCheap and exprIsExpandable) with that for exprIsWorkFree. Result is simpler, tighter, easier to understand. And correct (at least wrt this bug)! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 14:39:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 14:39:19 -0000 Subject: [GHC] #13156: CSE missing an easy case In-Reply-To: <046.e75b8366dc8aaa94cd7e951008b64c50@haskell.org> References: <046.e75b8366dc8aaa94cd7e951008b64c50@haskell.org> Message-ID: <061.2d73bd2019c69531a23890a19019894f@haskell.org> #13156: CSE missing an easy case -------------------------------------+------------------------------------- Reporter: simonpj | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b78fa759bfb405e3dc20d5e4bbb088989d17eb8b/ghc" b78fa759/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b78fa759bfb405e3dc20d5e4bbb088989d17eb8b" Simplify and improve CSE Trac #13156 showed a lost opportunity for CSE. I found that it was easy to fix, and it had the nice side effect of rendering a previous nasty case, described in Note [Corner case for case expressions], unnecessary. Simpler code, does more. Great. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 14:39:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 14:39:19 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.5d18ba5901bc20dfdbbbdecd0eaec836@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b8f1b018312d83a4c7a760ef3a5cf2bb067bfbf0/ghc" b8f1b01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b8f1b018312d83a4c7a760ef3a5cf2bb067bfbf0" Test Trac #11444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 15:43:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 15:43:31 -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.88254784cf94d6187488d749cafe4315@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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => T7102a, T7102 * differential: => Phab:D2994 Comment: There are actually two issues in this ticket. * The original issue, that you can replace type family instances in ghci as in comment:1. There was special logic to allow this (copied from the case of class instances), so fixing it was just deleting code (that I was going to have to change anyways, for another issue). I added test `T7102a` for this one. * The issue in comment:7 is different, and doesn't rely on the two instances having the same LHS. It's apparently not that ghci is replacing one instance with the other one, but rather that it never checks that the two instances are consistent with each other. So we need an additional consistency check somewhere. I haven't fixed this yet, but I added a expect_broken test `T7102` for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 15:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 15:46:52 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.9bdaa1ff2312ec60f4124c8a60ef96a6@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- Reporter: erikd | Owner: dfeuer 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: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Lots of other primops with IO-ish type do have `can_fail` and `has_side_effects` set though, even "read-only" ones like {{{ readMutVar# :: MutVar# s a -> State# s -> (# State# s, a #) }}} I know that it's not exactly a convincing argument that `seq#` needs the flags, but it makes me wonder... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 15:57:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 15:57:07 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.a478efda6425742e3482f267b691e379@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11444 Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T11444 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 15:58:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 15:58:22 -0000 Subject: [GHC] #13155: exprIsExpandable bug In-Reply-To: <046.ba7c808d6e462cf5fe9d4c7979057bdc@haskell.org> References: <046.ba7c808d6e462cf5fe9d4c7979057bdc@haskell.org> Message-ID: <061.6313d60a23d597222fe6256e5c4009d2@haskell.org> #13155: exprIsExpandable bug -------------------------------------+------------------------------------- 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: | simplCore/should_compile/T13155 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T13155 * resolution: => fixed Comment: It's hard to trigger this bug so probably not worth back-porting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 15:58:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 15:58:51 -0000 Subject: [GHC] #13156: CSE missing an easy case In-Reply-To: <046.e75b8366dc8aaa94cd7e951008b64c50@haskell.org> References: <046.e75b8366dc8aaa94cd7e951008b64c50@haskell.org> Message-ID: <061.bdfa9f4d74e053ab3362e92e1adc7e53@haskell.org> #13156: CSE missing an easy case -------------------------------------+------------------------------------- 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: | simplCore/should_compile/T13156 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T13156 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 18:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 18:35:56 -0000 Subject: [GHC] #13158: Pattern synonyms should use type annotation information when typechecking Message-ID: <050.659214f5530244fc33d6e67036d296e2@haskell.org> #13158: Pattern synonyms should use type annotation information when typechecking -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a small boatload of GHC extensions, I can write a view pattern with `Data.Typeable` that will simulate something like case analysis on types: {{{#!hs {-# LANGUAGE GADTs, PatternSynonyms, ScopedTypeVariables, TypeApplications, TypeOperators, ViewPatterns #-} import Data.Typeable viewEqT :: forall b a. (Typeable a, Typeable b) => a -> Maybe ((a :~: b), b) viewEqT x = case eqT @a @b of Just Refl -> Just (Refl, x) Nothing -> Nothing evilId :: Typeable a => a -> a evilId (viewEqT @Int -> Just (Refl, n)) = n + 1 evilId (viewEqT @String -> Just (Refl, str)) = reverse str evilId x = x }}} However, this is ugly. I would like to clean things up with a nice pattern synonym: {{{#!hs pattern EqT :: forall b a. (Typeable a, Typeable b) => (a ~ b) => b -> a pattern EqT x <- (viewEqT @b -> Just (Refl, x)) }}} Sadly, while this pattern typechecks, using it seems to be impossible. This program is rejected: {{{#!hs evilId :: Typeable a => a -> a evilId (EqT (n :: Int)) = n + 1 evilId (EqT (str :: String)) = reverse str evilId x = x }}} Specifically, it produces the following type error: {{{ /private/tmp/wild-patterns-sandbox/library/TypeEqTest.hs:17:9: error: • Could not deduce (Typeable b0) arising from a pattern from the context: Typeable a bound by the type signature for: evilId :: Typeable a => a -> a at library/TypeEqTest.hs:16:1-30 The type variable ‘b0’ is ambiguous • In the pattern: EqT (n :: Int) In an equation for ‘evilId’: evilId (EqT (n :: Int)) = n + 1 /private/tmp/wild-patterns-sandbox/library/TypeEqTest.hs:17:14: error: • Could not deduce: a ~ Int from the context: a ~ b0 bound by a pattern with pattern synonym: EqT :: forall b a. (Typeable a, Typeable b) => a ~ b => b -> a, in an equation for ‘evilId’ at library/TypeEqTest.hs:17:9-22 ‘a’ is a rigid type variable bound by the type signature for: evilId :: forall a. Typeable a => a -> a at library/TypeEqTest.hs:16:11 Expected type: Int Actual type: b0 • When checking that the pattern signature: Int fits the type of its context: b0 In the pattern: n :: Int In the pattern: EqT (n :: Int) • Relevant bindings include evilId :: a -> a (bound at library/TypeEqTest.hs:17:1) /private/tmp/wild-patterns-sandbox/library/TypeEqTest.hs:18:9: error: • Could not deduce (Typeable b1) arising from a pattern from the context: Typeable a bound by the type signature for: evilId :: Typeable a => a -> a at library/TypeEqTest.hs:16:1-30 The type variable ‘b1’ is ambiguous • In the pattern: EqT (str :: String) In an equation for ‘evilId’: evilId (EqT (str :: String)) = reverse str /private/tmp/wild-patterns-sandbox/library/TypeEqTest.hs:18:14: error: • Could not deduce: a ~ String from the context: a ~ b1 bound by a pattern with pattern synonym: EqT :: forall b a. (Typeable a, Typeable b) => a ~ b => b -> a, in an equation for ‘evilId’ at library/TypeEqTest.hs:18:9-27 ‘a’ is a rigid type variable bound by the type signature for: evilId :: forall a. Typeable a => a -> a at library/TypeEqTest.hs:16:11 Expected type: String Actual type: b1 • When checking that the pattern signature: String fits the type of its context: b1 In the pattern: str :: String In the pattern: EqT (str :: String) • Relevant bindings include evilId :: a -> a (bound at library/TypeEqTest.hs:17:1) }}} I would expect the program to typecheck, since in any other context, GHC would not have any trouble inferring the type of `b` for each use of `EqT`. However, it seems that pattern synonyms do not allow me to provide any type information “in”, only get type information “out”. Is there some fundamental limitation that forces this to be the case, or is this just a missing feature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 18:43:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 18:43:03 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.c29f278037f0f15f608e6e7c59a7a026@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7026edc37331d067c47e4a3506590a39c22f82d3/ghc" 7026edc3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7026edc37331d067c47e4a3506590a39c22f82d3" Add 'type family (m :: Symbol) <> (n :: Symbol)' Reviewers: dfeuer, austin, bgamari, hvr Subscribers: dfeuer, mpickering, RyanGlScott, ekmett, yav, lelf, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2632 GHC Trac Issues: #12162 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 18:48:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 18:48:42 -0000 Subject: [GHC] #13159: Allow visible type application with pattern synonyms in patterns Message-ID: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> #13159: Allow visible type application with pattern synonyms in patterns -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #13158 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Somewhat related to #13158, it would be nice if pattern synonyms allowed visible type application with the `TypeApplications` extension enabled. This would obviously be tricky due to the existing meaning of `@` in patterns, though I think it would technically be unambiguous here. Still, I’d understand if you didn’t want to complicate the parser that much further. The motivator, though, is that it would be nice to be able to write pattern synonyms with ambiguous types an explicitly instantiate them, for the same reason type applications are useful for terms. As mentioned in #13158, this would permit writing a pattern synonym to emulate case analysis on types: {{{#!hs {-# LANGUAGE GADTs, PatternSynonyms, ScopedTypeVariables, TypeApplications, TypeOperators, ViewPatterns #-} import Data.Typeable viewEqT :: forall b a. (Typeable a, Typeable b) => a -> Maybe ((a :~: b), b) viewEqT x = case eqT @a @b of Just Refl -> Just (Refl, x) Nothing -> Nothing pattern EqT :: forall b a. (Typeable a, Typeable b) => (a ~ b) => b -> a pattern EqT x <- (viewEqT @b -> Just (Refl, x)) }}} If visible type applications were permitted in patterns, then such case analysis could be written like this: {{{#!hs evilId :: Typeable a => a -> a evilId (EqT @Int n) = n + 1 evilId (EqT @String str) = reverse str evilId x = x }}} …which I think looks relatively pleasant! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 18:49:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 18:49:47 -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.9f967dd54fe64fc5b1b2b15b88543c67@haskell.org> #13158: Pattern synonyms should use type annotation information when typechecking -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | 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: #13159 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lexi.lambda): * related: => #13159 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 19:16:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 19:16:36 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.21687201e2b714aba9d47b54ad2197d8@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 19:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 19:42:39 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.0411e550da5f322fb502e752d87fe32f@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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): Replying to [comment:5 RyanGlScott]: > {{{#!hs > newtype ZipList a = ZipList [a] > deriving newtype (Functor, Foldable) > deriving unsafenewtype (Traversable) > }}} Interesting. I believe this is probably safe even if the underlying `Applicative` and `Traversable` are bogus, thanks to polymorphism. We are coercing `f (t b)` to `f (u b)`. The usual concern with such a coercion is that `f` could have an index rather than a parameter, so matching on the result of the coercion could falsely reveal that `t ~ u`. But `traverse` can only construct `f` values using `pure`, `<*>`, and the given function. Of those, only the given function could produce values carrying evidence. But they can carry evidence only about `b`, not about `t`. So it looks like coercing the result of `traverse` to a representationally identical container with the same element type is ''probably'' okay. > Granted, this is a separate hack to get around the fact that we don't have higher-kinded roles yet, but it's (IMO) much nicer to use than having to manually inline the definition of `traverse` like you demonstrated above. Can you explain how higher-kinded roles would help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 19:52:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 19:52:53 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.6f25fd4212d03103ca753fbd77ae5a4a@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d49b2bb21691892ca6ac8f2403e31f2a5e53feb3/ghc" d49b2bb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d49b2bb21691892ca6ac8f2403e31f2a5e53feb3" Allow top-level string literals in Core (#8472) This commits relaxes the invariants of the Core syntax so that a top-level variable can be bound to a primitive string literal of type Addr#. This commit: * Relaxes the invatiants of the Core, and allows top-level bindings whose type is Addr# as long as their RHS is either a primitive string literal or another variable. * Allows the simplifier and the full-laziness transformer to float out primitive string literals to the top leve. * Introduces the new StgGenTopBinding type to accomodate top-level Addr# bindings. * Introduces a new type of labels in the object code, with the suffix "_bytes", for exported top-level Addr# bindings. * Makes some built-in rules more robust. This was necessary to keep them functional after the above changes. This is a continuation of D2554. Rebasing notes: This had two slightly suspicious performance regressions: * T12425: bytes allocated regressed by roughly 5% * T4029: bytes allocated regressed by a bit over 1% * T13035: bytes allocated regressed by a bit over 5% These deserve additional investigation. Rebased by: bgamari. Test Plan: ./validate --slow Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari Reviewed By: trofi, simonpj, bgamari Subscribers: trofi, simonpj, gridaphobe, thomie Differential Revision: https://phabricator.haskell.org/D2605 GHC Trac Issues: #8472 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 20:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 20:24:20 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.e2b712685c5bdce95384249b033ed981@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 RyanGlScott): * cc: goldfire (added) Comment: > Can you explain how higher-kinded roles would help? Hm, I thought I meant higher-kinded roles, but now I recall Richard telling me that he thought those were inferior to normal roles + [https://ghc.haskell.org/trac/ghc/ticket/2256 implication constraints] (I've cc'd him in case I totally butcher this). So let me instead explain how those would help :) The current issue that prevents you from writing this: {{{#!hs newtype Wrapped inner a = Wrap { unwrap :: inner a } deriving (Functor, Foldable) instance Traversable inner => Traversable (Wrapped inner) where traverse = coerce traverse }}} is that we need to coerce from `(a -> f b) -> inner a -> f (inner b)` to `(a -> f b) -> Wrapped a -> f (Wrapped b)` for some `f`. That is, we need to prove `Coercible (f (inner b)) (f (Wrapped b))`. But we don't know this //a priori//. `f` is some arbitrary type variable, so we have to be conservative and assume its role is nominal. That prevents us from coercing underneath `f`, so we can't conclude `Coercible (f (inner b)) (f (Wrapped b))`. But what if we could modify the `Traversable` instance to require this coercibility property as part of the instance context? It sure would be great if we could just write this: {{{#!hs instance (Coercible (f (inner b)) (f (Wrapped inner b)), Traversable inner) => Traversable (Wrapped inner) where traverse :: forall f a b. Applicative f => (a -> f b) -> Wrapped inner a -> f (Wrapped inner b) traverse = coerce (traverse :: (a -> f b) -> Wrapped inner a -> f (Wrapped inner b)) }}} But sadly, this won't work, since the `b` and the `f` in in the instance context can't scope over the class methods. What [https://ghc.haskell.org/trac/ghc/ticket/9123#comment:29 implication constraints] would let you do here is write this: {{{#!hs instance (forall f b. Applicative f => Coercible (f (inner b)) (f (Wrapped inner b)), Traversable inner) => Traversable (Wrapped inner) where traverse :: forall f a b. Applicative f => (a -> f b) -> Wrapped inner a -> f (Wrapped inner b) traverse = coerce (traverse :: (a -> f b) -> Wrapped inner a -> f (Wrapped inner b)) }}} Notice that we're now able to stick a `forall` inside of an instance context, something which GHC currently forbids! The idea here being that this `forall f a b. Applicative f => Coercible (f (inner b)) (f (Wrapped inner b))` would get fed into the constraint solver and could be used to conclude that `Coercible (f (inner b)) (f (Wrapped b))` works for //any// `f` and `b` (where `f` is `Applicative`). But do keep in mind that user-visible implication constraints are nothing but a feature request at the moment, so all the above is hypothetical. Until some wonderful day in the future when we have this, the escape hatch is `unsafeCoerce`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 21:45:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 21:45:21 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.26100b4af27ac4c1acaef1506636b907@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: philderbeast Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: | Differential Rev(s): Phab:D2734 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"33140f41b931fb81bf2e5aa28603fe757bb3779d/ghc" 33140f4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="33140f41b931fb81bf2e5aa28603fe757bb3779d" Show explicit quantifiers in conflicting definitions error This fixes #12441, where definitions in a Haskell module and its boot file which differed only in their quantifiers produced a confusing error message. Here we teach GHC to always show quantifiers for these errors. Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari Reviewed By: bgamari Subscribers: snowleopard, simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2734 GHC Trac Issues: #12441 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 21:45:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 21:45:21 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.3d7020820388cf081dfb28d053e3fc0b@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- Reporter: rwbarton | 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 Ben Gamari ): In [changeset:"b47613178232f8e849ac58ebd4111a34ab9c140b/ghc" b4761317/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b47613178232f8e849ac58ebd4111a34ab9c140b" Add a failing test for #13099 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2990 GHC Trac Issues: #13099 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 21:45:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 21:45:38 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.2c7bf5cbbb1ba7cee1a7f0868b8500a6@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | 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: | Differential Rev(s): Phab:D2734 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: philderbeast => * status: patch => new * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 21:46:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 21:46:06 -0000 Subject: [GHC] #13099: recompilation can fail to recheck type family instance consistency In-Reply-To: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> References: <047.59effe1500ff525a6569ec5ac47010d3@haskell.org> Message-ID: <062.e8907e65e7bbf0a7e30c3ef7113e06c4@haskell.org> #13099: recompilation can fail to recheck type family instance consistency -------------------------------------+------------------------------------- Reporter: rwbarton | 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: recomp017 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => recomp017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 22:25:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 22:25:49 -0000 Subject: [GHC] #13129: Warn about home module not listed on command line In-Reply-To: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> References: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> Message-ID: <059.d97522f8addec3f6cdfc1584977056a1@haskell.org> #13129: Warn about home module not listed on command line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2977 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"15b9a85ef03e2729d487a6f8460be8880c797609/ghc" 15b9a85e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="15b9a85ef03e2729d487a6f8460be8880c797609" Warn on missing home modules Introduce a warning, -Wmissing-home-modules, to warn about home modules, not listed in command line. It is usefull for cabal when user fails to list a module in `exposed-modules` and `other-modules`. Test Plan: make TEST=MissingMod Reviewers: mpickering, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2977 GHC Trac Issues: #13129 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 22:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 22:26:23 -0000 Subject: [GHC] #13129: Warn about home module not listed on command line In-Reply-To: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> References: <044.cbe903231753a83571fbfe53a8d668d2@haskell.org> Message-ID: <059.ea8c240140f20728a0b2ad236dfc8204@haskell.org> #13129: Warn about home module not listed on command line -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | 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:D2977 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 Fri Jan 20 22:52:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 22:52:58 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.901f97299ca383c49cc0acab91e9d088@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Did this turn out to be the issue with uniques overflowing? Or was that something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 22:55:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 22:55:16 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.6b0db9c1cc7b31832a6f65429ab2f836@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ocharles): * status: new => closed * resolution: => fixed Comment: I think so - haven't seen a panic since! Let's go ahead and close this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 22:59:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 22:59:24 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.a77fd6c96a37380144bc356d328d92c0@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Great. (Wanted to make sure I wasn't confusing this with a different issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 23:02:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 23:02:11 -0000 Subject: [GHC] #12663: amazonka-ec2 fails to build with --split-objs In-Reply-To: <048.229708a11b5fa85980c94db5223a3842@haskell.org> References: <048.229708a11b5fa85980c94db5223a3842@haskell.org> Message-ID: <063.a80978bb07e1d25235a1a1a7177d7a79@haskell.org> #12663: amazonka-ec2 fails to build with --split-objs -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Could you test with 8.0.2? This looks like it might be the same issue underlying #12899. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 20 23:03:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jan 2017 23:03:19 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310515=3A_ghc=3A_panic=3A_tyThingTyC?= =?utf-8?b?b24gSWRlbnRpZmllciDigJgkZlN0ZW5jaWw6LmEoLCwsLCk34oCZ?= In-Reply-To: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> References: <046.1a69329a1db1e1b89b8b31699fd5aae1@haskell.org> Message-ID: <061.76e34ac8f76435a0adf9e86e6c6fe6ea@haskell.org> #10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Guessing this might have been caused by the underlying issue of #12899. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 00:01:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 00:01:44 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn Message-ID: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> #13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- When introducing type-in-type, Richard elaborated the free varaible finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 00:02:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 00:02:32 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn In-Reply-To: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> References: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> Message-ID: <061.61fa4dcf1cd904312c504ddb20fb6271@haskell.org> #13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * owner: => goldfire * type: bug => task * milestone: => 8.2.1 @@ -30,1 +30,1 @@ - Richard will do this when he gets a moment. + Richard will do this when he gets a moment. But I really hope for 8.2 New description: When introducing type-in-type, Richard elaborated the free varaible finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. But I really hope for 8.2 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 00:11:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 00:11:32 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.adc9ce8c01cf98fe02907eeb17bc9748@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- Reporter: erikd | Owner: dfeuer 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: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Yes, but they really do have side effects. It matters when they are executed, and it matters if they are not executed at all. That said, I doubt it would matter if the (badly named) `seq#` also had these attributes. I wish I could think of an obviously-correct way to reason about this, rather than simply not being able to see a problem. Simon Marlow may be able to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 00:13:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 00:13:48 -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.c5e25611e67ebd8a04c60de8580e110b@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 oerjan): Perhaps the error message for the instance overlap could mention (if in GHCi) that you can get around it by redeclaring the type family. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 01:01:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 01:01:45 -0000 Subject: [GHC] #12750: hGetContents leads to late/silent failures In-Reply-To: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> References: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> Message-ID: <070.aaf13877a43b09dc13e7f0708ce77e4a@haskell.org> #12750: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: massimo.zaniboni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | https://github.com/massimo- | zaniboni/ghc_lazy_file_content_error Blocked By: | Blocking: Related Tickets: #9236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > `hGetContents` closes automatically the handle when the end of the file is reached. But in case of actions with exceptions, the end of the file could be not reached and the handle can be left temporally open, before the garbage collector reclaim it. That's right. It's normally no big deal to leave a file handle open for a little while. If this is a problem for you, then don't use `hGetContents`. > So the suggested pattern is managing file handles inside `bracket` resource management functions. But this can introduce problems in case of lazy evaluations, because the code processing the file content can be called after the handle is closed. Indeed, mixing `hGetContents` and `bracket` isn't recommended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 01:16:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 01:16:02 -0000 Subject: [GHC] #12556: `stimes` adds extra power to Semigroup In-Reply-To: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> References: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> Message-ID: <066.1cc68e441be2f33b71c14482654a3248@haskell.org> #12556: `stimes` adds extra power to Semigroup -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | 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 rwbarton): It doesn't seem like a problem to me if a particular `Semigroup`'s `stimes` is more defined than the default definition would be, as long as that extension is reasonable, i.e., a monoid homomorphism. Even allowing negative arguments would be reasonable if the `Semigroup` happens to be a group. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 09:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 09:42:25 -0000 Subject: [GHC] #12750: hGetContents leads to late/silent failures In-Reply-To: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> References: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> Message-ID: <070.f65ad816f5f6e79a7260c02fc9fef78b@haskell.org> #12750: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: massimo.zaniboni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | https://github.com/massimo- | zaniboni/ghc_lazy_file_content_error Blocked By: | Blocking: Related Tickets: #9236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by massimo.zaniboni): Replying to [comment:2 rwbarton]: > Indeed, mixing `hGetContents` and `bracket` isn't recommended. I like lazy functions like `Data.Text.Lazy.hGetContents` because I can process file content chunk by chunk using a constant amount of RAM, and the code is very elegant. In any case the problem is related to any type of lazy evaluation using a resource managed by `bracket`, so not only `hGetContents`. More clearly there are two bugs: 1) when the code reads the content of a closed file handle, instead of returning a run-time exception, a normal EOF is returned, and the application code has a bad behavior, because normal code path is executed instead of processing the exception. 2) `bracket` does not work well with resources processed in a lazy way, because the thunk using the resource can be used after `bracket` has closed it, generating unexpected run-time errors. So the best semantic of `bracket` should be a strict evaluation of the result. It is a behavior more predictable and similar to Resource Acquisition Is Initialization (RAII) semantic of C++. But probably this is not the best place for signaling this. By the way I solved the problem executing with strict semantic all the file processing instructions inside `bracket`. File content is still processed chunk by chunk, but the handle is closed only at the end, when the result is returned. So my work-around rule is: use `bracket` only with strict semantic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 12:38:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 12:38:09 -0000 Subject: [GHC] #13161: Unexpected error about untouchable variable Message-ID: <046.71521d854360f3a0b03321165873dad9@haskell.org> #13161: Unexpected error about untouchable variable -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: 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: -------------------------------------+------------------------------------- Hello! I've got a strange error here. Let's consider the following code: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} module Main where data X data Expr a = Expr Int type family Sum a b type instance Sum X X = X app :: Expr l -> (Expr l') -> m (Expr (Sum l l')) app = undefined finish :: Builder (Expr l) -> Builder (Expr X) finish = undefined type family Foo (m :: * -> *) :: * -> * class (Monad m, Foo (Foo m) ~ Foo m) => Ctx (m :: * -> *) newtype Builder a = Builder (forall m. Ctx m => m a) f :: Builder (Expr X) -> Builder (Expr X) -> Builder (Expr X) -> Builder (Expr X) f mop ma mb = finish $ Builder $ app (undefined :: (Expr X)) (undefined :: (Expr X)) main :: IO () main = return () }}} it results in error: {{{ UT.hs:24:34: error: • Couldn't match type ‘l0’ with ‘X’ ‘l0’ is untouchable inside the constraints: Ctx m bound by a type expected by the context: Ctx m => m (Expr l0) at UT.hs:24:24-84 Expected type: m (Expr l0) Actual type: m (Expr (Sum X X)) • In the second argument of ‘($)’, namely ‘app (undefined :: Expr X) (undefined :: Expr X)’ In the second argument of ‘($)’, namely ‘Builder $ app (undefined :: Expr X) (undefined :: Expr X)’ In the expression: finish $ Builder $ app (undefined :: Expr X) (undefined :: Expr X) }}} And that's very interesting, because it should (according to my knowledge) not happen. It is caused by the line: `finish $ Builder $ app (undefined :: (Expr X)) (undefined :: (Expr X))`. And we can observe here couple of things. First of all `app :: Expr l -> (Expr l') -> m (Expr (Sum l l'))` and `Sum X X = X`, so `app (undefined :: (Expr X)) (undefined :: (Expr X)) :: Expr X` - and GHC can clearly see it. What is more interesting is that if we put this signature explicitly it works! So If we change the error line to: {{{ ... f mop ma mb = finish $ (Builder $ app (undefined :: (Expr X)) (undefined :: (Expr X)) :: Builder (Expr X) }}} it compiles fine. Another interesting fact is that if I remove the constraint `Foo (Foo m) ~ Foo m` it also compiles fine, which is even more strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 12:57:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 12:57:08 -0000 Subject: [GHC] #13162: Testsuite driver has problems reliably removing files Message-ID: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> #13162: Testsuite driver has problems reliably removing files ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2936 | Wiki Page: ----------------------------------------+---------------------------- Testsuite has sporadic failures while trying to remove the previous test output. This presents itself in a number of ways in the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 13:12:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 13:12:37 -0000 Subject: [GHC] #13142: Core simplifier crashes while building stack. (was: GHC emits enormous core starting with 'Arity decrease') In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.dba02bad6ef14ecb943530bbea7b2a47@haskell.org> #13142: Core simplifier crashes while building stack. -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): * cc: Simonpj (added) * failure: None/Unknown => Compile-time crash or panic Comment: Thanks for the report, It would be nice if you had a smaller example or one that didn't use stack to reproduce this. I don't know if this is triggered by an issue in stack, but the simplifier shouldn't be crashing. Any ideas Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 13:30:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 13:30:07 -0000 Subject: [GHC] #9223: Type equality makes type variable untouchable In-Reply-To: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> References: <048.6ce33f316f2e616ec0311d809cccfbe7@haskell.org> Message-ID: <063.e69c8d9c4355eedabc94e8658021babc@haskell.org> #9223: Type equality makes type variable untouchable -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): I just realized my ticket may be connected to this one! If it is we could merge them: https://ghc.haskell.org/trac/ghc/ticket/13161#ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 16:41:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 16:41:15 -0000 Subject: [GHC] #13163: Make type import/export API Annotation friendly Message-ID: <044.7fe6260ca2f7eb764d1cf3fd5f011712@haskell.org> #13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment an export of the form {{{#!hs type C(..) }}} is parsed by the rule {{{ | 'type' oqtycon {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2))) [mj AnnType $1,mj AnnVal $2] } }}} This means that the origiinal `oqtycon` loses its location which is then retained in the `AnnVal` annotation. The problem is if the `oqtycon` has its own annotations, these get lost. e.g. in {{{#!hs type (?)(..) }}} the parens annotations for `(?)` get lost. This can be solved by introducing a new `IE` constructor `IEVarType`, treated exactly the same as `IEVar` in the rest of the processing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 19:48:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 19:48:46 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.d96f5a46777034661f2a8b681154ca41@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2998 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by nakaji_dayo): * status: new => patch * differential: => D2998 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 20:33:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 20:33:39 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) Message-ID: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: idle GC | 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 an interactive program I noticed idle CPU usage of ~12% due to the full GCs done by the RTS on default settings. For this specific usecase this is a lot of wasted CPU cycles for no gain. Passing {{{-I0}}} to the RTS "fixes" this; nonetheless I think that the default behaviour could/should be improved, even when considering other usecases where full GCs are a good choice. The program in question keeps ~50MB allocated on the heap but does close to no short-lived allocations in between the idle GCs. Some relevant data from the summary: {{{ 930,569,008 bytes allocated in the heap 4,847,446,928 bytes copied during GC 46,255,056 bytes maximum residency (111 sample(s)) 378,200 bytes maximum slop 94 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1784 colls, 0 par 0.123s 0.100s 0.0001s 0.0006s Gen 1 111 colls, 0 par 9.377s 9.418s 0.0848s 0.1099s INIT time 0.000s ( 0.003s elapsed) MUT time 2.250s ( 95.029s elapsed) GC time 9.500s ( 9.518s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.007s ( 0.008s elapsed) Total time 11.760s (104.557s elapsed) }}} The detailed GC statistics of the idle GCs look like {{{ Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 13304 45958728 46210536 0.070 0.068 0.920 1.550 0 0 (Gen: 1) 11568 45958720 46210536 0.100 0.102 1.043 2.584 0 0 (Gen: 1) 15432 45958720 46210536 0.103 0.105 1.167 3.588 0 0 (Gen: 1) 11568 45958720 46210536 0.100 0.102 1.287 4.586 0 0 (Gen: 1) 11568 45958720 46210536 0.107 0.107 1.413 5.592 0 0 (Gen: 1) 11568 45958720 46210536 0.073 0.080 1.503 6.566 0 0 (Gen: 1) 11568 45958720 46210536 0.073 0.073 1.593 7.560 0 0 (Gen: 1) 11568 45958720 46210536 0.067 0.068 1.677 8.557 0 0 (Gen: 1) }}} I don't really know what exactly "alloc bytes" means, but my guess is that those numbers are indeed fairly low and those GCs are mostly useless. To clarify the intention of this request: '''Tweak the idle GC (default) configuration in some way so that interactive programs with moderate heap use reasonable amount of CPU time while idle.''' And "reasonable" is intentionally vague as I don't know how to weight other usecases. Minimal example: {{{ import Control.Concurrent main :: IO () main = do let large = [1..1000000] print $ length large [1..20] `forM_` \_ -> do threadDelay 400000 print $ sum large }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 21:30:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 21:30:15 -0000 Subject: [GHC] #13165: Speed up the RTS hash table Message-ID: <047.5597063b110123c6100b4b707918365d@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StablePtr` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 22:51:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 22:51:40 -0000 Subject: [GHC] #13142: Core simplifier crashes while building stack. In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.7d53f75595505a0aaafb71822967a63c@haskell.org> #13142: Core simplifier crashes while building stack. -------------------------------------+------------------------------------- Reporter: jeiea | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: Windows => Unknown/Multiple Comment: A couple of clarifications: 1. This isn't OS-specific - I can also reproduce it on Windows. 2. This has nothing to do with `stack` in particular, but rather one of its dependencies, `store`. (Aside: `store` is gaining a reputation for causing GHC bugs. See also #13059.) 3. This relies on building `store` with a debugging compiler (In fact, why is `stack` using a debugging compiler in the first place? Weird.) I tried to trim `store` down into as small of an example as I possibly could. Here's what I came up with: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UndecidableInstances #-} module StoreBug () where import Data.Foldable (foldl') import Data.Proxy import Data.Word import Foreign.Storable (Storable, sizeOf) import GHC.Generics import GHC.Types (Int(..)) import GHC.TypeLits newtype Type = VarT Name deriving Generic data Name = Name OccName NameFlavour deriving Generic data NameFlavour = NameS | NameQ ModName | NameU !Int | NameL !Int | NameG PkgName ModName deriving Generic newtype ModName = ModName String deriving Generic newtype PkgName = PkgName String deriving Generic newtype OccName = OccName String deriving Generic instance Store Type instance Store Name instance Store NameFlavour instance Store ModName instance Store OccName instance Store PkgName instance Store Char where {-# INLINE size #-} size = sizeStorableTy "Foreign.Storable.Storable GHC.Types.Char" instance Store Int where {-# INLINE size #-} size = undefined instance Store a => Store [a] where size = sizeSequence {-# INLINE size #-} sizeSequence :: forall a. Store a => Size [a] sizeSequence = VarSize $ \t -> case size :: Size a of ConstSize n -> n * (length t) + sizeOf (undefined :: Int) VarSize f -> foldl' (\acc x -> acc + f x) (sizeOf (undefined :: Int)) t {-# INLINE sizeSequence #-} class Store a where size :: Size a default size :: (Generic a, GStoreSize (Rep a)) => Size a size = genericSize {-# INLINE size #-} data Size a = VarSize (a -> Int) | ConstSize !Int getSizeWith :: Size a -> a -> Int getSizeWith (VarSize f) x = f x getSizeWith (ConstSize n) _ = n {-# INLINE getSizeWith #-} contramapSize :: (a -> b) -> Size b -> Size a contramapSize f (VarSize g) = VarSize (g . f) contramapSize _ (ConstSize n) = ConstSize n {-# INLINE contramapSize #-} combineSizeWith :: forall a b c. (c -> a) -> (c -> b) -> Size a -> Size b -> Size c combineSizeWith toA toB sizeA sizeB = case (sizeA, sizeB) of (VarSize f, VarSize g) -> VarSize (\x -> f (toA x) + g (toB x)) (VarSize f, ConstSize m) -> VarSize (\x -> f (toA x) + m) (ConstSize n, VarSize g) -> VarSize (\x -> n + g (toB x)) (ConstSize n, ConstSize m) -> ConstSize (n + m) {-# INLINE combineSizeWith #-} sizeStorableTy :: forall a. Storable a => String -> Size a sizeStorableTy ty = ConstSize (sizeOf (error msg :: a)) where msg = "In Data.Store.storableSize: " ++ ty ++ "'s sizeOf evaluated its argument." {-# INLINE sizeStorableTy #-} genericSize :: (Generic a, GStoreSize (Rep a)) => Size a genericSize = contramapSize from gsize {-# INLINE genericSize #-} type family SumArity (a :: * -> *) :: Nat where SumArity (C1 c a) = 1 SumArity (x :+: y) = SumArity x + SumArity y class GStoreSize f where gsize :: Size (f a) instance GStoreSize f => GStoreSize (M1 i c f) where gsize = contramapSize unM1 gsize {-# INLINE gsize #-} instance Store a => GStoreSize (K1 i a) where gsize = contramapSize unK1 size {-# INLINE gsize #-} instance GStoreSize U1 where gsize = ConstSize 0 {-# INLINE gsize #-} instance GStoreSize V1 where gsize = ConstSize 0 {-# INLINE gsize #-} instance (GStoreSize a, GStoreSize b) => GStoreSize (a :*: b) where gsize = combineSizeWith (\(x :*: _) -> x) (\(_ :*: y) -> y) gsize gsize {-# INLINE gsize #-} instance (SumArity (a :+: b) <= 255, GStoreSizeSum 0 (a :+: b)) => GStoreSize (a :+: b) where gsize = VarSize $ \x -> sizeOf (undefined :: Word8) + gsizeSum x (Proxy :: Proxy 0) {-# INLINE gsize #-} class KnownNat n => GStoreSizeSum (n :: Nat) (f :: * -> *) where gsizeSum :: f a -> Proxy n -> Int instance (GStoreSizeSum n a, GStoreSizeSum (n + SumArity a) b, KnownNat n) => GStoreSizeSum n (a :+: b) where gsizeSum (L1 l) _ = gsizeSum l (Proxy :: Proxy n) gsizeSum (R1 r) _ = gsizeSum r (Proxy :: Proxy (n + SumArity a)) {-# INLINE gsizeSum #-} instance (GStoreSize a, KnownNat n) => GStoreSizeSum n (C1 c a) where gsizeSum x _ = getSizeWith gsize x {-# INLINE gsizeSum #-} }}} And here's the panic I get when I compile it with a debug-enabled GHC HEAD: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 -fforce-recomp -O2 StoreBug.hs [1 of 1] Compiling StoreBug ( StoreBug.hs, StoreBug.o ) WARNING: file compiler/simplCore/SimplCore.hs, line 666 Simplifier bailing out after 4 iterations [3866, 755, 220, 8] Size = {terms: 1,490, types: 7,176, coercions: 4,808} ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170121 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 wild_X25 g1_a33l g2_a33m $cfrom_a47d $cto_a47F $cfrom_a48a $cto_a48C $cfrom_a496 $cto_a4bk $cfrom_a4dA $cto_a4e2 $cfrom_a4ew $cto_a4fb $cfrom_a4fS $cto_a4gk $cp1GStoreSizeSum_a4gV $cgsizeSum_a4gX $cp1GStoreSizeSum_a4hh $cgsizeSum_a4hj $cgsize_a4hV $cgsize_a4ix $csize_a4iU $csize_a4j2 $csize_a4jb $csize_a4jj $csize_a4jw $csize_a4jJ $csize_a4jW $csize_a4k9 $csize_a4km $cgsize_a4kD $cgsize_a4kY $cgsize_a4l6 $cgsize_a4li $dGStoreSize_a4qQ $dGStoreSize_a4qW $dGStoreSize_a4r2 $dGStoreSize_a4r8 $dGStoreSize_a4BJ $dGStoreSize_a4BS ww2_a5CX sizeSequence genericSize $tc'ModName $tcModName $tc'PkgName $tcPkgName $tc'NameS $tc'NameQ $tc'NameU $tc'NameL $tc'NameG $tcNameFlavour $tc'OccName $tcOccName $tc'Name $tcName $tc'VarT $tcType $tc'VarSize $tc'ConstSize $tcSize $tcGStoreSize $tc'C:GStoreSize $fGStoreSize:*: $fGStoreSizeV1 $fGStoreSizeU1 $fGStoreSizeM1 $tcStore $dmsize $tc'C:Store $fGStoreSizeK1 $fStore[] $fStoreInt $fStoreChar $fStorePkgName $fStoreOccName $fStoreModName $fStoreNameFlavour $fStoreName $fStoreType $tcGStoreSizeSum $tc'C:GStoreSizeSum $fGStoreSizeSumnM1 $fGStoreSizeSumn:+: $fGStoreSize:+: $fGenericModName $fGenericPkgName $fGenericNameFlavour $fGenericOccName $fGenericName $fGenericType $trModule $cto_s4Pr $cfrom_s4Ps $cfrom_s4Pv $cto_s4Pw $cfrom_s4Px $cfrom_s4PF $cto_s4PG $cfrom_s4PH $cto_s4PI $cfrom_s4PJ $trModule_s50k $trModule_s50l $trModule_s50m $trModule_s50n $tc'ModName_s50o $tc'ModName_s50p $tcModName_s50q $tcModName_s50r $tc'PkgName_s50s $tc'PkgName_s50t $tcPkgName_s50u $tcPkgName_s50v $tc'NameG_s50w $tc'NameG_s50x $tc'NameL_s50y $tc'NameL_s50z $tc'NameU_s50A $tc'NameU_s50B $tc'NameQ_s50C $tc'NameQ_s50D $tc'NameS_s50E $tc'NameS_s50F $tcNameFlavour_s50G $tcNameFlavour_s50H $tc'OccName_s50I $tc'OccName_s50J $tcOccName_s50K $tcOccName_s50L $tc'Name_s50M $tc'Name_s50N $tcName_s50O $tcName_s50P $tc'VarT_s50Q $tc'VarT_s50R $tcType_s50S $tcType_s50T $tc'ConstSize_s50U $tc'ConstSize_s50V $tc'VarSize_s50W $tc'VarSize_s50X $tcSize_s50Y $tcSize_s50Z $tc'C:GStoreSize_s510 $tc'C:GStoreSize_s511 $tcGStoreSize_s512 $tcGStoreSize_s513 $tc'C:Store_s514 $tc'C:Store_s515 $tcStore_s516 $tcStore_s517 $tc'C:GStoreSizeSum_s518 $tc'C:GStoreSizeSum_s519 $tcGStoreSizeSum_s51a $tcGStoreSizeSum_s51b $sgenericSize_s59c $sgenericSize_s59f $sgenericSize_s59i $sgenericSize_s59l $sgenericSize_s59o $sgenericSize_s59r $sgsize_s59B $sgsize_s59D $sgsize_s59F $sgsize_s59H $sgsize_s59J $sgsize_s59L lvl_s5bw lvl_s5bx $csize_s5i3 $dGStoreSize_s5jy $dGStoreSize_s5jM $dGStoreSize_s5k0 $dGStoreSize_s5kc $dGStoreSize_s5lQ $dGStoreSize_s5od $dGStoreSize_s5rC g_s5tx g_s5tA g_s5tD $dGStoreSize_s5u4 g_s5u5 $dGStoreSize_s5uv $dGStoreSize_s5uZ $sgenericSize_s5v0 $csize_s5v2 g_s5vy $sgenericSize_s5vA $csize_s5vF $w$j_s5Wr a_s5Ws ww_s5Ww ww_s5Wx $wg_s5WC $w$dGStoreSize_s5WI $wg_s5WT lvl_s65L lvl_s65M lvl_s65N lvl_s65O lvl_s65P lvl_s65Q lvl_s65R lvl_s65S lvl_s65T lvl_s65U lvl_s65W lvl_s65X lvl_s65Y lvl_s65Z lvl_s660 lvl_s661 lvl_s662 lvl_s663 lvl_s664 lvl_s665 lvl_s666 lvl_s667 lvl_s66c lvl_s66d lvl_s66e lvl_s66f lvl_s66g lvl_s66h lvl_s66i lvl_s66j lvl_s66k lvl_s66l lvl_s66m lvl_s66n lvl_s66s lvl_s66t lvl_s66u lvl_s66v lvl_s66w lvl_s66x lvl_s66y lvl_s66z lvl_s66A lvl_s66B lvl_s66C lvl_s66D lvl_s66I lvl_s66J lvl_s66K lvl_s66L $s$w$j_s69S $s$w$j_s69T $s$w$j_s69U} tenv [] tenvFVs [] cenv [s69R :-> sg_s69R] cenvFVs [s69R :-> sg_s69R] tys [R] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1215:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2078:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2111:17 in ghc:TyCoRep substTy, called at compiler/types/OptCoercion.hs:345:12 in ghc:OptCoercion 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/utils/Outputable.hs:1213:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2078:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2111:17 in ghc:TyCoRep substTy, called at compiler/types/OptCoercion.hs:345:12 in ghc:OptCoercion }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 21 23:15:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jan 2017 23:15:42 -0000 Subject: [GHC] #13142: Substitution invariant failure arising from OptCoercion (was: Core simplifier crashes while building stack.) In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.4f4c4e67b913aa8fd46e9b8c8a1b258b@haskell.org> #13142: Substitution invariant failure arising from OptCoercion -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Determinism 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): * keywords: => Determinism @@ -1,5 +1,315 @@ - I discovered this when building - [https://github.com/commercialhaskell/stack/commit/f117ffb034658e3e1c3fea2a88972c685b4558e1 - stack] by stack on windows 10. - - I want to find problem area, but I can't even catch a clue. + When built with a debugging compiler, the following snippet fails because + of the substitution invariant. + + {{{ + {-# LANGUAGE BangPatterns #-} + {-# LANGUAGE DataKinds #-} + {-# LANGUAGE DefaultSignatures #-} + {-# LANGUAGE DeriveFunctor #-} + {-# LANGUAGE DeriveGeneric #-} + {-# LANGUAGE EmptyCase #-} + {-# LANGUAGE FlexibleContexts #-} + {-# LANGUAGE FlexibleInstances #-} + {-# LANGUAGE KindSignatures #-} + {-# LANGUAGE MagicHash #-} + {-# LANGUAGE MultiParamTypeClasses #-} + {-# LANGUAGE RankNTypes #-} + {-# LANGUAGE ScopedTypeVariables #-} + {-# LANGUAGE TypeFamilies #-} + {-# LANGUAGE TypeOperators #-} + {-# LANGUAGE UnboxedTuples #-} + {-# LANGUAGE UndecidableInstances #-} + module StoreBug () where + + import Data.Foldable (foldl') + import Data.Proxy + import Data.Word + import Foreign.Storable (Storable, sizeOf) + import GHC.Generics + import GHC.Types (Int(..)) + import GHC.TypeLits + + newtype Type = VarT Name + deriving Generic + + data Name = Name OccName NameFlavour + deriving Generic + + data NameFlavour + = NameS + | NameQ ModName + | NameU !Int + | NameL !Int + | NameG PkgName ModName + deriving Generic + + newtype ModName = ModName String + deriving Generic + + newtype PkgName = PkgName String + deriving Generic + + newtype OccName = OccName String + deriving Generic + + instance Store Type + instance Store Name + instance Store NameFlavour + instance Store ModName + instance Store OccName + instance Store PkgName + + instance Store Char where + {-# INLINE size #-} + size = sizeStorableTy "Foreign.Storable.Storable GHC.Types.Char" + + instance Store Int where + {-# INLINE size #-} + size = undefined + + instance Store a => Store [a] where + size = sizeSequence + {-# INLINE size #-} + + sizeSequence :: forall a. Store a => Size [a] + sizeSequence = VarSize $ \t -> + case size :: Size a of + ConstSize n -> n * (length t) + sizeOf (undefined :: Int) + VarSize f -> foldl' (\acc x -> acc + f x) (sizeOf (undefined :: + Int)) t + {-# INLINE sizeSequence #-} + + class Store a where + size :: Size a + + default size :: (Generic a, GStoreSize (Rep a)) => Size a + size = genericSize + {-# INLINE size #-} + + data Size a + = VarSize (a -> Int) + | ConstSize !Int + + getSizeWith :: Size a -> a -> Int + getSizeWith (VarSize f) x = f x + getSizeWith (ConstSize n) _ = n + {-# INLINE getSizeWith #-} + + contramapSize :: (a -> b) -> Size b -> Size a + contramapSize f (VarSize g) = VarSize (g . f) + contramapSize _ (ConstSize n) = ConstSize n + {-# INLINE contramapSize #-} + + combineSizeWith :: forall a b c. (c -> a) -> (c -> b) -> Size a -> Size b + -> Size c + combineSizeWith toA toB sizeA sizeB = + case (sizeA, sizeB) of + (VarSize f, VarSize g) -> VarSize (\x -> f (toA x) + g (toB x)) + (VarSize f, ConstSize m) -> VarSize (\x -> f (toA x) + m) + (ConstSize n, VarSize g) -> VarSize (\x -> n + g (toB x)) + (ConstSize n, ConstSize m) -> ConstSize (n + m) + {-# INLINE combineSizeWith #-} + + sizeStorableTy :: forall a. Storable a => String -> Size a + sizeStorableTy ty = ConstSize (sizeOf (error msg :: a)) + where + msg = "In Data.Store.storableSize: " ++ ty ++ "'s sizeOf evaluated its + argument." + {-# INLINE sizeStorableTy #-} + + genericSize :: (Generic a, GStoreSize (Rep a)) => Size a + genericSize = contramapSize from gsize + {-# INLINE genericSize #-} + + type family SumArity (a :: * -> *) :: Nat where + SumArity (C1 c a) = 1 + SumArity (x :+: y) = SumArity x + SumArity y + + class GStoreSize f where gsize :: Size (f a) + + instance GStoreSize f => GStoreSize (M1 i c f) where + gsize = contramapSize unM1 gsize + {-# INLINE gsize #-} + + instance Store a => GStoreSize (K1 i a) where + gsize = contramapSize unK1 size + {-# INLINE gsize #-} + + instance GStoreSize U1 where + gsize = ConstSize 0 + {-# INLINE gsize #-} + + instance GStoreSize V1 where + gsize = ConstSize 0 + {-# INLINE gsize #-} + + instance (GStoreSize a, GStoreSize b) => GStoreSize (a :*: b) where + gsize = combineSizeWith (\(x :*: _) -> x) (\(_ :*: y) -> y) gsize + gsize + {-# INLINE gsize #-} + + instance (SumArity (a :+: b) <= 255, GStoreSizeSum 0 (a :+: b)) + => GStoreSize (a :+: b) where + gsize = VarSize $ \x -> sizeOf (undefined :: Word8) + gsizeSum x + (Proxy :: Proxy 0) + {-# INLINE gsize #-} + + class KnownNat n => GStoreSizeSum (n :: Nat) (f :: * -> *) where gsizeSum + :: f a -> Proxy n -> Int + + instance (GStoreSizeSum n a, GStoreSizeSum (n + SumArity a) b, KnownNat n) + => GStoreSizeSum n (a :+: b) where + gsizeSum (L1 l) _ = gsizeSum l (Proxy :: Proxy n) + gsizeSum (R1 r) _ = gsizeSum r (Proxy :: Proxy (n + SumArity a)) + {-# INLINE gsizeSum #-} + + instance (GStoreSize a, KnownNat n) => GStoreSizeSum n (C1 c a) where + gsizeSum x _ = getSizeWith gsize x + {-# INLINE gsizeSum #-} + }}} + + The assertion failure is + + {{{ + $ ~/Software/ghc5/inplace/bin/ghc-stage2 -fforce-recomp -O2 StoreBug.hs + [1 of 1] Compiling StoreBug ( StoreBug.hs, StoreBug.o ) + WARNING: file compiler/simplCore/SimplCore.hs, line 666 + Simplifier bailing out after 4 iterations [3866, 755, 220, 8] + Size = {terms: 1,490, types: 7,176, coercions: 4,808} + ghc-stage2: panic! (the 'impossible' happened) + (GHC version 8.1.20170121 for x86_64-unknown-linux): + ASSERT failed! + in_scope InScope {wild_00 wild_X25 g1_a33l g2_a33m $cfrom_a47d + $cto_a47F $cfrom_a48a $cto_a48C $cfrom_a496 $cto_a4bk + $cfrom_a4dA + $cto_a4e2 $cfrom_a4ew $cto_a4fb $cfrom_a4fS $cto_a4gk + $cp1GStoreSizeSum_a4gV $cgsizeSum_a4gX + $cp1GStoreSizeSum_a4hh + $cgsizeSum_a4hj $cgsize_a4hV $cgsize_a4ix $csize_a4iU + $csize_a4j2 + $csize_a4jb $csize_a4jj $csize_a4jw $csize_a4jJ + $csize_a4jW + $csize_a4k9 $csize_a4km $cgsize_a4kD $cgsize_a4kY + $cgsize_a4l6 + $cgsize_a4li $dGStoreSize_a4qQ $dGStoreSize_a4qW + $dGStoreSize_a4r2 + $dGStoreSize_a4r8 $dGStoreSize_a4BJ $dGStoreSize_a4BS + ww2_a5CX + sizeSequence genericSize $tc'ModName $tcModName + $tc'PkgName + $tcPkgName $tc'NameS $tc'NameQ $tc'NameU $tc'NameL + $tc'NameG + $tcNameFlavour $tc'OccName $tcOccName $tc'Name $tcName + $tc'VarT + $tcType $tc'VarSize $tc'ConstSize $tcSize + $tcGStoreSize + $tc'C:GStoreSize $fGStoreSize:*: $fGStoreSizeV1 + $fGStoreSizeU1 + $fGStoreSizeM1 $tcStore $dmsize $tc'C:Store + $fGStoreSizeK1 + $fStore[] $fStoreInt $fStoreChar $fStorePkgName + $fStoreOccName + $fStoreModName $fStoreNameFlavour $fStoreName + $fStoreType + $tcGStoreSizeSum $tc'C:GStoreSizeSum + $fGStoreSizeSumnM1 + $fGStoreSizeSumn:+: $fGStoreSize:+: $fGenericModName + $fGenericPkgName $fGenericNameFlavour $fGenericOccName + $fGenericName $fGenericType $trModule $cto_s4Pr + $cfrom_s4Ps + $cfrom_s4Pv $cto_s4Pw $cfrom_s4Px $cfrom_s4PF + $cto_s4PG $cfrom_s4PH + $cto_s4PI $cfrom_s4PJ $trModule_s50k $trModule_s50l + $trModule_s50m + $trModule_s50n $tc'ModName_s50o $tc'ModName_s50p + $tcModName_s50q + $tcModName_s50r $tc'PkgName_s50s $tc'PkgName_s50t + $tcPkgName_s50u + $tcPkgName_s50v $tc'NameG_s50w $tc'NameG_s50x + $tc'NameL_s50y + $tc'NameL_s50z $tc'NameU_s50A $tc'NameU_s50B + $tc'NameQ_s50C + $tc'NameQ_s50D $tc'NameS_s50E $tc'NameS_s50F + $tcNameFlavour_s50G + $tcNameFlavour_s50H $tc'OccName_s50I $tc'OccName_s50J + $tcOccName_s50K $tcOccName_s50L $tc'Name_s50M + $tc'Name_s50N + $tcName_s50O $tcName_s50P $tc'VarT_s50Q $tc'VarT_s50R + $tcType_s50S + $tcType_s50T $tc'ConstSize_s50U $tc'ConstSize_s50V + $tc'VarSize_s50W + $tc'VarSize_s50X $tcSize_s50Y $tcSize_s50Z + $tc'C:GStoreSize_s510 + $tc'C:GStoreSize_s511 $tcGStoreSize_s512 + $tcGStoreSize_s513 + $tc'C:Store_s514 $tc'C:Store_s515 $tcStore_s516 + $tcStore_s517 + $tc'C:GStoreSizeSum_s518 $tc'C:GStoreSizeSum_s519 + $tcGStoreSizeSum_s51a $tcGStoreSizeSum_s51b + $sgenericSize_s59c + $sgenericSize_s59f $sgenericSize_s59i + $sgenericSize_s59l + $sgenericSize_s59o $sgenericSize_s59r $sgsize_s59B + $sgsize_s59D + $sgsize_s59F $sgsize_s59H $sgsize_s59J $sgsize_s59L + lvl_s5bw + lvl_s5bx $csize_s5i3 $dGStoreSize_s5jy + $dGStoreSize_s5jM + $dGStoreSize_s5k0 $dGStoreSize_s5kc $dGStoreSize_s5lQ + $dGStoreSize_s5od $dGStoreSize_s5rC g_s5tx g_s5tA + g_s5tD + $dGStoreSize_s5u4 g_s5u5 $dGStoreSize_s5uv + $dGStoreSize_s5uZ + $sgenericSize_s5v0 $csize_s5v2 g_s5vy + $sgenericSize_s5vA + $csize_s5vF $w$j_s5Wr a_s5Ws ww_s5Ww ww_s5Wx $wg_s5WC + $w$dGStoreSize_s5WI $wg_s5WT lvl_s65L lvl_s65M + lvl_s65N lvl_s65O + lvl_s65P lvl_s65Q lvl_s65R lvl_s65S lvl_s65T lvl_s65U + lvl_s65W + lvl_s65X lvl_s65Y lvl_s65Z lvl_s660 lvl_s661 lvl_s662 + lvl_s663 + lvl_s664 lvl_s665 lvl_s666 lvl_s667 lvl_s66c lvl_s66d + lvl_s66e + lvl_s66f lvl_s66g lvl_s66h lvl_s66i lvl_s66j lvl_s66k + lvl_s66l + lvl_s66m lvl_s66n lvl_s66s lvl_s66t lvl_s66u lvl_s66v + lvl_s66w + lvl_s66x lvl_s66y lvl_s66z lvl_s66A lvl_s66B lvl_s66C + lvl_s66D + lvl_s66I lvl_s66J lvl_s66K lvl_s66L $s$w$j_s69S + $s$w$j_s69T + $s$w$j_s69U} + tenv [] + tenvFVs [] + cenv [s69R :-> sg_s69R] + cenvFVs [s69R :-> sg_s69R] + tys [R] + cos [] + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at + compiler/utils/Outputable.hs:1166:58 in ghc:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:1215:22 in + ghc:Outputable + assertPprPanic, called at compiler/types/TyCoRep.hs:2078:56 in + ghc:TyCoRep + checkValidSubst, called at compiler/types/TyCoRep.hs:2111:17 in + ghc:TyCoRep + substTy, called at compiler/types/OptCoercion.hs:345:12 in + ghc:OptCoercion + 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/utils/Outputable.hs:1213:5 in + ghc:Outputable + assertPprPanic, called at compiler/types/TyCoRep.hs:2078:56 in + ghc:TyCoRep + checkValidSubst, called at compiler/types/TyCoRep.hs:2111:17 in + ghc:TyCoRep + substTy, called at compiler/types/OptCoercion.hs:345:12 in + ghc:OptCoercion + }}} New description: When built with a debugging compiler, the following snippet fails because of the substitution invariant. {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UndecidableInstances #-} module StoreBug () where import Data.Foldable (foldl') import Data.Proxy import Data.Word import Foreign.Storable (Storable, sizeOf) import GHC.Generics import GHC.Types (Int(..)) import GHC.TypeLits newtype Type = VarT Name deriving Generic data Name = Name OccName NameFlavour deriving Generic data NameFlavour = NameS | NameQ ModName | NameU !Int | NameL !Int | NameG PkgName ModName deriving Generic newtype ModName = ModName String deriving Generic newtype PkgName = PkgName String deriving Generic newtype OccName = OccName String deriving Generic instance Store Type instance Store Name instance Store NameFlavour instance Store ModName instance Store OccName instance Store PkgName instance Store Char where {-# INLINE size #-} size = sizeStorableTy "Foreign.Storable.Storable GHC.Types.Char" instance Store Int where {-# INLINE size #-} size = undefined instance Store a => Store [a] where size = sizeSequence {-# INLINE size #-} sizeSequence :: forall a. Store a => Size [a] sizeSequence = VarSize $ \t -> case size :: Size a of ConstSize n -> n * (length t) + sizeOf (undefined :: Int) VarSize f -> foldl' (\acc x -> acc + f x) (sizeOf (undefined :: Int)) t {-# INLINE sizeSequence #-} class Store a where size :: Size a default size :: (Generic a, GStoreSize (Rep a)) => Size a size = genericSize {-# INLINE size #-} data Size a = VarSize (a -> Int) | ConstSize !Int getSizeWith :: Size a -> a -> Int getSizeWith (VarSize f) x = f x getSizeWith (ConstSize n) _ = n {-# INLINE getSizeWith #-} contramapSize :: (a -> b) -> Size b -> Size a contramapSize f (VarSize g) = VarSize (g . f) contramapSize _ (ConstSize n) = ConstSize n {-# INLINE contramapSize #-} combineSizeWith :: forall a b c. (c -> a) -> (c -> b) -> Size a -> Size b -> Size c combineSizeWith toA toB sizeA sizeB = case (sizeA, sizeB) of (VarSize f, VarSize g) -> VarSize (\x -> f (toA x) + g (toB x)) (VarSize f, ConstSize m) -> VarSize (\x -> f (toA x) + m) (ConstSize n, VarSize g) -> VarSize (\x -> n + g (toB x)) (ConstSize n, ConstSize m) -> ConstSize (n + m) {-# INLINE combineSizeWith #-} sizeStorableTy :: forall a. Storable a => String -> Size a sizeStorableTy ty = ConstSize (sizeOf (error msg :: a)) where msg = "In Data.Store.storableSize: " ++ ty ++ "'s sizeOf evaluated its argument." {-# INLINE sizeStorableTy #-} genericSize :: (Generic a, GStoreSize (Rep a)) => Size a genericSize = contramapSize from gsize {-# INLINE genericSize #-} type family SumArity (a :: * -> *) :: Nat where SumArity (C1 c a) = 1 SumArity (x :+: y) = SumArity x + SumArity y class GStoreSize f where gsize :: Size (f a) instance GStoreSize f => GStoreSize (M1 i c f) where gsize = contramapSize unM1 gsize {-# INLINE gsize #-} instance Store a => GStoreSize (K1 i a) where gsize = contramapSize unK1 size {-# INLINE gsize #-} instance GStoreSize U1 where gsize = ConstSize 0 {-# INLINE gsize #-} instance GStoreSize V1 where gsize = ConstSize 0 {-# INLINE gsize #-} instance (GStoreSize a, GStoreSize b) => GStoreSize (a :*: b) where gsize = combineSizeWith (\(x :*: _) -> x) (\(_ :*: y) -> y) gsize gsize {-# INLINE gsize #-} instance (SumArity (a :+: b) <= 255, GStoreSizeSum 0 (a :+: b)) => GStoreSize (a :+: b) where gsize = VarSize $ \x -> sizeOf (undefined :: Word8) + gsizeSum x (Proxy :: Proxy 0) {-# INLINE gsize #-} class KnownNat n => GStoreSizeSum (n :: Nat) (f :: * -> *) where gsizeSum :: f a -> Proxy n -> Int instance (GStoreSizeSum n a, GStoreSizeSum (n + SumArity a) b, KnownNat n) => GStoreSizeSum n (a :+: b) where gsizeSum (L1 l) _ = gsizeSum l (Proxy :: Proxy n) gsizeSum (R1 r) _ = gsizeSum r (Proxy :: Proxy (n + SumArity a)) {-# INLINE gsizeSum #-} instance (GStoreSize a, KnownNat n) => GStoreSizeSum n (C1 c a) where gsizeSum x _ = getSizeWith gsize x {-# INLINE gsizeSum #-} }}} The assertion failure is {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 -fforce-recomp -O2 StoreBug.hs [1 of 1] Compiling StoreBug ( StoreBug.hs, StoreBug.o ) WARNING: file compiler/simplCore/SimplCore.hs, line 666 Simplifier bailing out after 4 iterations [3866, 755, 220, 8] Size = {terms: 1,490, types: 7,176, coercions: 4,808} ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170121 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 wild_X25 g1_a33l g2_a33m $cfrom_a47d $cto_a47F $cfrom_a48a $cto_a48C $cfrom_a496 $cto_a4bk $cfrom_a4dA $cto_a4e2 $cfrom_a4ew $cto_a4fb $cfrom_a4fS $cto_a4gk $cp1GStoreSizeSum_a4gV $cgsizeSum_a4gX $cp1GStoreSizeSum_a4hh $cgsizeSum_a4hj $cgsize_a4hV $cgsize_a4ix $csize_a4iU $csize_a4j2 $csize_a4jb $csize_a4jj $csize_a4jw $csize_a4jJ $csize_a4jW $csize_a4k9 $csize_a4km $cgsize_a4kD $cgsize_a4kY $cgsize_a4l6 $cgsize_a4li $dGStoreSize_a4qQ $dGStoreSize_a4qW $dGStoreSize_a4r2 $dGStoreSize_a4r8 $dGStoreSize_a4BJ $dGStoreSize_a4BS ww2_a5CX sizeSequence genericSize $tc'ModName $tcModName $tc'PkgName $tcPkgName $tc'NameS $tc'NameQ $tc'NameU $tc'NameL $tc'NameG $tcNameFlavour $tc'OccName $tcOccName $tc'Name $tcName $tc'VarT $tcType $tc'VarSize $tc'ConstSize $tcSize $tcGStoreSize $tc'C:GStoreSize $fGStoreSize:*: $fGStoreSizeV1 $fGStoreSizeU1 $fGStoreSizeM1 $tcStore $dmsize $tc'C:Store $fGStoreSizeK1 $fStore[] $fStoreInt $fStoreChar $fStorePkgName $fStoreOccName $fStoreModName $fStoreNameFlavour $fStoreName $fStoreType $tcGStoreSizeSum $tc'C:GStoreSizeSum $fGStoreSizeSumnM1 $fGStoreSizeSumn:+: $fGStoreSize:+: $fGenericModName $fGenericPkgName $fGenericNameFlavour $fGenericOccName $fGenericName $fGenericType $trModule $cto_s4Pr $cfrom_s4Ps $cfrom_s4Pv $cto_s4Pw $cfrom_s4Px $cfrom_s4PF $cto_s4PG $cfrom_s4PH $cto_s4PI $cfrom_s4PJ $trModule_s50k $trModule_s50l $trModule_s50m $trModule_s50n $tc'ModName_s50o $tc'ModName_s50p $tcModName_s50q $tcModName_s50r $tc'PkgName_s50s $tc'PkgName_s50t $tcPkgName_s50u $tcPkgName_s50v $tc'NameG_s50w $tc'NameG_s50x $tc'NameL_s50y $tc'NameL_s50z $tc'NameU_s50A $tc'NameU_s50B $tc'NameQ_s50C $tc'NameQ_s50D $tc'NameS_s50E $tc'NameS_s50F $tcNameFlavour_s50G $tcNameFlavour_s50H $tc'OccName_s50I $tc'OccName_s50J $tcOccName_s50K $tcOccName_s50L $tc'Name_s50M $tc'Name_s50N $tcName_s50O $tcName_s50P $tc'VarT_s50Q $tc'VarT_s50R $tcType_s50S $tcType_s50T $tc'ConstSize_s50U $tc'ConstSize_s50V $tc'VarSize_s50W $tc'VarSize_s50X $tcSize_s50Y $tcSize_s50Z $tc'C:GStoreSize_s510 $tc'C:GStoreSize_s511 $tcGStoreSize_s512 $tcGStoreSize_s513 $tc'C:Store_s514 $tc'C:Store_s515 $tcStore_s516 $tcStore_s517 $tc'C:GStoreSizeSum_s518 $tc'C:GStoreSizeSum_s519 $tcGStoreSizeSum_s51a $tcGStoreSizeSum_s51b $sgenericSize_s59c $sgenericSize_s59f $sgenericSize_s59i $sgenericSize_s59l $sgenericSize_s59o $sgenericSize_s59r $sgsize_s59B $sgsize_s59D $sgsize_s59F $sgsize_s59H $sgsize_s59J $sgsize_s59L lvl_s5bw lvl_s5bx $csize_s5i3 $dGStoreSize_s5jy $dGStoreSize_s5jM $dGStoreSize_s5k0 $dGStoreSize_s5kc $dGStoreSize_s5lQ $dGStoreSize_s5od $dGStoreSize_s5rC g_s5tx g_s5tA g_s5tD $dGStoreSize_s5u4 g_s5u5 $dGStoreSize_s5uv $dGStoreSize_s5uZ $sgenericSize_s5v0 $csize_s5v2 g_s5vy $sgenericSize_s5vA $csize_s5vF $w$j_s5Wr a_s5Ws ww_s5Ww ww_s5Wx $wg_s5WC $w$dGStoreSize_s5WI $wg_s5WT lvl_s65L lvl_s65M lvl_s65N lvl_s65O lvl_s65P lvl_s65Q lvl_s65R lvl_s65S lvl_s65T lvl_s65U lvl_s65W lvl_s65X lvl_s65Y lvl_s65Z lvl_s660 lvl_s661 lvl_s662 lvl_s663 lvl_s664 lvl_s665 lvl_s666 lvl_s667 lvl_s66c lvl_s66d lvl_s66e lvl_s66f lvl_s66g lvl_s66h lvl_s66i lvl_s66j lvl_s66k lvl_s66l lvl_s66m lvl_s66n lvl_s66s lvl_s66t lvl_s66u lvl_s66v lvl_s66w lvl_s66x lvl_s66y lvl_s66z lvl_s66A lvl_s66B lvl_s66C lvl_s66D lvl_s66I lvl_s66J lvl_s66K lvl_s66L $s$w$j_s69S $s$w$j_s69T $s$w$j_s69U} tenv [] tenvFVs [] cenv [s69R :-> sg_s69R] cenvFVs [s69R :-> sg_s69R] tys [R] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1215:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2078:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2111:17 in ghc:TyCoRep substTy, called at compiler/types/OptCoercion.hs:345:12 in ghc:OptCoercion 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/utils/Outputable.hs:1213:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2078:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2111:17 in ghc:TyCoRep substTy, called at compiler/types/OptCoercion.hs:345:12 in ghc:OptCoercion }}} -- Comment: Wow, great job Ryan once again. It does appear to be a bug but probably a harmless one, the answer is to try using a normal version of the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 03:19:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 03:19:58 -0000 Subject: [GHC] #13142: Substitution invariant failure arising from OptCoercion In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.6258b17565fc73bbe3c802e64cbbe22e@haskell.org> #13142: Substitution invariant failure arising from OptCoercion -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Determinism 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 Phyx-): I wouldn't say the answer is ignoring the assert, if it is then what's the point of the assert? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 08:26:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 08:26:28 -0000 Subject: [GHC] #13142: Substitution invariant failure arising from OptCoercion In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.e60d4ce3f62ec3c3643f6b6ddf7e94f6@haskell.org> #13142: Substitution invariant failure arising from OptCoercion -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Determinism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #11371 Comment: #11371 is related. There are still about 40 calls in the compiler where this isn't checked at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 14:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 14:08:27 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.ed3cfd30c43db9469090797b4c133996@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -26,0 +26,4 @@ + ---- + + An example that is tricky for me is `calculateBmi w h = w / h^2`. + New description: Operator fixity can be a source of bugs (even for experienced users!),[#point1 ¹] [#point2 ²] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{#!hs ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. ---- An example that is tricky for me is `calculateBmi w h = w / h^2`. [=#point1 ¹] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] [=#point2 ²] [http://ieeexplore.ieee.org/document/7548903/?platform=hootsuite Brace Yourself] ([https://twitter.com/ieeesoftware/status/791882437295038464 tweet]) -- Comment (by Iceland_jack): No -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 14:39:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 14:39:09 -0000 Subject: [GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories Message-ID: <049.6a1b9c307bb6fdef29527ef20d8e76fc@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- I'm not exactly sure yet where this is coming from, but I'd like to report an warning on Windows during preprocessing phase: {{{ [00:03:39] Preprocessing library cardano-sl-0.1.0.0... [00:03:39] Warning: Can't find file "C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h" in directories [00:03:39] src/Pos [00:03:39] . [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] .stack-work\dist\b7fec021\build\autogen [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] C:\OpenSSL-Win64\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include [00:03:39] C:\projects\pos-haskell-prototype\rocksdb\include [00:03:39] C:\OpenSSL-Win64\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include [00:03:39] C:\projects\pos-haskell-prototype\rocksdb\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1 \vector-algorithms-0.7.0.1-8R8UpWgvBC926XMxBjYPpx\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\zlib-0.6.1.2-4CWLN1T27kOJhNvXgy46ZV\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\process-1.4.2.0\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\old- time-1.1.0.3-IcvdkJUsE9M8t3io8peAEp\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\directory-1.2.6.2\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\time-1.6.0.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\Win32-2.3.1.1\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\network-2.6.3.1-nK9qnsiJR03CWuPIGMmX\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\bytestring-0.10.8.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\base-4.9.0.0\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib \integer-gmp-1.0.0.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include [00:03:39] Asked for by: src/Pos/CLI.hs at line 2 col 1 }}} It appears to trigger for each module using cpphs. The file is present, so I suspect the problem is in unix path character in `C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h`. Using verbose mode we can observe that's the case: {{{ "cpphs" "-DWITH_WEB" "-DWITH_WALLET" "-include" ".stack- work\dist\ca59d0ab\build\autogen\cabal_macros.h" "--cpp" "-I" ".stack- work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build\autogen" "-I" ".stack- work\dist\ca59d0ab\build" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\include" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\includ e" "-I" "C:\sr\snapshots\b3566c00\lib\x86_64-windows-ghc-8.0.2\vector- algorithms-0.7.0.1-C2u1KYklHg84I6SQQVEAin\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\zlib-0.6.1.2-7negTfm2ujt1gW4wr40MUp\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\process-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\vector-0.11.0.0-LMwQhhnXj8U3T5Bm1JFxG\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\old- time-1.1.0.3-KWRsMSdY26c2L27Y9n9cyq\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\directory-1.2.6.2-qiZgXsB5o98ZsOYUWltfF\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\primitive-0.6.1.0-6AbSTw9JXz141LE5p6LGH\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\time-1.6.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\Win32-2.3.1.1\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\network-2.6.3.1-AwRxOQvT8JM9e8zDFK7aCI\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\bytestring-0.10.8. 1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\base-4.9.1.0\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib \integer-gmp-1.0.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include" "-D__GLASGOW_HASKELL__=800" "-include" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include\ghcversion.h" "-Dmingw32_BUILD_OS=1" "-Dx86_64_BUILD_ARCH=1" "-Dmingw32_HOST_OS=1" "-Dx86_64_HOST_ARCH=1" "-D__GLASGOW_HASKELL_TH__=1" "-D_ _SSE__=1" "-D__SSE2__=1" "-includeC:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_18.h" "-x" "assembler-with-cpp" "src\Pos\Binary\Crypto.hs" "-o" "C:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_17.hscpp" }}} I highly suspect https://github.com/ghc/ghc/blob/master/utils/ghc- pkg/Main.hs#L1956 since it does some unclear path mungling, probably leaving undosified suffix. Note that those functions were copied from `compiler/main/SysTools.hs` which changed significantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 14:47:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 14:47:57 -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.275e94060c48028a9fc457d3a6f76705@haskell.org> #13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): It seems the `type` keyword can appear in two different places in an export, so something like {{{#!hs type A(type B,C,..) }}} is valid. In this case `A` can be wrapped in an `IEVarType`, but `B` is a `RdrName` currently. Is this correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 14:50:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 14:50:08 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions Message-ID: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | 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: -------------------------------------+------------------------------------- When GC runs a number of finalizers in a row, and the first of them throws an exception, then other finalizers are ignored. The relevant piece of code is [https://github.com/ghc/ghc/blob/fb4092642f057f258d07cd6979925f4e2579eda6/libraries/base/GHC/Weak.hs#L144 here]. The following program reproduces the issue: {{{ import Data.IORef import Control.Monad import Control.Exception import System.Mem main :: IO () main = do run run run run performMajorGC performMajorGC run :: IO () run = do ref <- newIORef () void $ mkWeakIORef ref $ do putStr "." throwIO $ ErrorCall "failed" }}} I expect it to output "....", but I get only "." The issue makes it unsafe to rely on finalizer for resource cleanup because unrelated finalizer (e.g. from some other library) may prevent your finalizer from running. Actually I was sure the issue is known, but today I tried to find a reference to it, and failed. If it is by design, then it should be documented somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 16:05:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 16:05:16 -0000 Subject: [GHC] #13161: Unexpected error about untouchable variable In-Reply-To: <046.71521d854360f3a0b03321165873dad9@haskell.org> References: <046.71521d854360f3a0b03321165873dad9@haskell.org> Message-ID: <061.e167e1608781df2586455241cc5e8868@haskell.org> #13161: Unexpected error about untouchable variable -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This is expected behavior, for a sufficiently nuanced expectation. The argument to builder is type-checked with an assumed equality, `Foo (Foo m) ~ Foo m`. Type variables brought into scope outside an assumed equality cannot be influenced by anything that arises with an equality assumption, because perhaps the equality assumption affects how that outer variable should be solved. In your case, GHC must infer the index `a` to the type `Builder`. We see that `a` should be `Expr l` for some `l`, looking at the type of `finish`. But what `l`? The only way to know would be to unify `l` with `X`, the result of the `app` -- but that `X` was derived with an assumed equality in scope. So we have an error. It is fixed by your type signature, which tells GHC what `l` should be, and it is fixed by removing the equality assumption, which avoid triggering the "untouchable variable" behavior. The beginning of section 5 of the [https://www.microsoft.com/en- us/research/publication/outsideinx-modular-type-inference-with-local- assumptions/ OutsideIn paper] gives a nice introduction to untouchable variables, accessible to intermediate (or better) Haskell programmers and with no need to read anything before section 5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 16:05:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 16:05:37 -0000 Subject: [GHC] #13161: Unexpected error about untouchable variable In-Reply-To: <046.71521d854360f3a0b03321165873dad9@haskell.org> References: <046.71521d854360f3a0b03321165873dad9@haskell.org> Message-ID: <061.5d98ed05a21f239d4b756291f8450cd5@haskell.org> #13161: Unexpected error about untouchable variable -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): If you're satisfied with this answer, please close the ticket. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 16:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 16:20:55 -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.efbbfdcaaf10cb9dc0a174a45888f2a4@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: infoneeded Priority: low | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded Comment: How can we reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 17:02:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 17:02:09 -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.f84c7e5b8cc9c34c2a341f9d9e6347ad@haskell.org> #13158: Pattern synonyms should use type annotation information when typechecking -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | 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: #13159 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Your code looks reasonable to me and should be accepted. My guess is that this is just a type-checking bug, but I've not looked at the GHC code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 17:04:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 17:04:05 -0000 Subject: [GHC] #13159: Allow visible type application with pattern synonyms in patterns In-Reply-To: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> References: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> Message-ID: <065.bb9e77f31e7b7294e5335f739559511d@haskell.org> #13159: Allow visible type application with pattern synonyms in patterns -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #13158, #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #13158 => #13158, #11350 Comment: Very related to #11350, the ticket requesting type applications in patterns, in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 17:04:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 17:04:32 -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.d76762d00fef87c16f5f0bf56832de41@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: #11385 => #11385, #13159 Comment: #13159 discusses this idea w.r.t. pattern synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 17:06:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 17:06:35 -0000 Subject: [GHC] #13159: Allow visible type application with pattern synonyms in patterns In-Reply-To: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> References: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> Message-ID: <065.ed88acdf0dfd5e6dc726dd7a4dcb1499@haskell.org> #13159: Allow visible type application with pattern synonyms in patterns -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #13158, #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this, #13158 and #11350 should all be considered the same as each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 17:10:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 17:10:15 -0000 Subject: [GHC] #13159: Allow visible type application with pattern synonyms in patterns In-Reply-To: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> References: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> Message-ID: <065.2f6e64cdaa53a27bf09b03690ee2ebc6@haskell.org> #13159: Allow visible type application with pattern synonyms in patterns -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #13158, #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think #13158 is not fundamentally related here, except as motivation. Perhaps this could be combined with #11350. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 17:14:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 17:14:57 -0000 Subject: [GHC] #13159: Allow visible type application with pattern synonyms in patterns In-Reply-To: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> References: <050.341fe799e55bb936136378aaf74f47f0@haskell.org> Message-ID: <065.d498a76c4ad8ab1a79690309e327b2a8@haskell.org> #13159: Allow visible type application with pattern synonyms in patterns -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | 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: #13158, #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: Yes, my mistake. I will close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 18:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 18:40:15 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.b117e4d8cdf6650baee799a845794a92@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: 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 crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Phab:D2931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"560bc289fc6a5b308f985d4c84e0cdf1f88c55fd/ghc" 560bc289/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="560bc289fc6a5b308f985d4c84e0cdf1f88c55fd" Revert "Remove unnecessary isTyVar tests in TcType" Summary: This reverts commit a0899b2f66a4102a7cf21569889381446ce63833. This is because removing these checks prompts panics in at least two different programs reported in #12785. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2931 GHC Trac Issues: #12785 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 18:41:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 18:41:39 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.0adf76dea6e3f5450daea9ee85ca8d45@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | 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: Compile-time | Test Case: crash or panic | typecheck/should_compile/T12785a, | typecheck/should_fail/T12785b Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Phab:D2931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: yes => typecheck/should_compile/T12785a, typecheck/should_fail/T12785b * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 19:03:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 19:03:24 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports Message-ID: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Originally reported in https://github.com/haskell/cabal/issues/4253, but I moved it here after being reassured that this was a GHCi bug, not a `Cabal` one. To reproduce this issue, you'll need to install two libraries that export two constructors with the same name. The original issue uses `GLFW` and `GLFW-b` as examples, but for the puposes of test case minimalization, I've prepared a repo here (https://github.com/RyanGlScott/cabal-gh4253) with as small of an example as I can manage. To reproduce the issue, do the following: {{{ $ git clone https://github.com/RyanGlScott/cabal-gh4253 $ cd cabal-gh4253/ $ cabal install package1/ package2/ $ ghci -XPackageImports GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import "package1" DuplicateModuleName λ> Window :1:1: error: Ambiguous interface for ‘DuplicateModuleName’: it was found in multiple packages: package1-0.1.0.0 package2-0.1.0.0 }}} This seems to be specific to GHCi, because I cannot find a way to trigger the same issue with `ghc --make`. I've reproduced this with GHC 8.0.2 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 19:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 19:10:44 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.d8890a163e0a70b053c69211e359268a@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 19:25:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 19:25:30 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.995b7d047a08f4354a613cab5f8aaf4b@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: 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): Another issue with this approach is that the finalizer would not be registered by `addModFinalizer` but it is carried in the AST instead. If the user discards the result of the inner splice, the finalizer wouldn't run. The following expression does not run the finalizer, because exp carries the finalizers and it is not used in the result of the outermost splice. {{{ $(do exp@(SplicedE here_we_carry_the_finalizers (TupE [])) <- [| $(addModFinalizer (runIO (putStrLn "finalizer")) >> [| () |] ) |] [| () |] ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 19:43:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 19:43:58 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.58ded73dfbcc6a496dc95aa85302cbc5@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #5979 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 19:44:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 19:44:07 -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.e3f7dbf85d3dd098d3038d4dd289cf7c@haskell.org> #12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie 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:"5d38fb69fd1e7a434ccc3147ae6a17fe0b5b0be3/ghc" 5d38fb69/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d38fb69fd1e7a434ccc3147ae6a17fe0b5b0be3" Remove clean_cmd and extra_clean usage from .T files The `clean_cmd` and `extra_clean` setup functions don't do anything. Remove them from .T files. Created using https://github.com/thomie/refactor-ghc-testsuite. This diff is a test for the .T-file parser/processor/pretty-printer in that repository. find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \; Tests containing inline comments or multiline strings are not modified. Preparation for #12223. Test Plan: Harbormaster Reviewers: austin, hvr, simonmar, mpickering, bgamari Reviewed By: mpickering Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D3000 GHC Trac Issues: #12223 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 22 20:11:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jan 2017 20:11:11 -0000 Subject: [GHC] #13149: Giving Backpack a Promotion In-Reply-To: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> References: <045.e76a1987b474b4a053f53d31cd2a8629@haskell.org> Message-ID: <060.801a7e011207b36cc5caeb76717ec7ce@haskell.org> #13149: Giving Backpack a Promotion -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | 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: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"9ef237b7ca816edb65126d3e2d0eea649f8c9db7/ghc" 9ef237b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ef237b7ca816edb65126d3e2d0eea649f8c9db7" Failing test for #13149. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 00:16:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 00:16:30 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.206c3d70ac887ecf41860fe5ba52856e@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: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 01:15:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 01:15:42 -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.586037632d3311db222108ca17e9d270@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: I seem to recall hvr didn't want another gmp binary tarball added to the ghc repo. I'll try to implement fetching of the gmp release tarballs as part of the build process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 01:30:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 01:30:50 -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.373f4f1e8fc1472a8b49d35196032590@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * priority: high => highest * owner: rwbarton => Comment: Never mind, I guess automatically fetching things from the network is unacceptable. hvr: what am I supposed to do here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 01:31:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 01:31:00 -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.225b9c9eb5e51123646ae91d4c344e85@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 01:34:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 01:34:13 -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.9acbe4912350083f865399d0a004c28e@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): hvr, I'm going to add the new tarball to the repo unless this gets resolved in another way within the next week (since the branch is a little more than a week away). Okay? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 01:58:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 01:58:53 -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.3f57e423babcf97aad7b1224fc797d58@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): A suggestion is for now to just turn `libraries/integer-gmp/gmp/tarball` into a submodule `gmp-tarballs.git`, so we can add the new GMP tarball to it, without permanently increasing the size of `ghc.git`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 02:07:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 02:07:33 -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.d7647bb4cf157731b5ef0911d03450a0@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): Another suggestion is to add to the repo a big patch file that we apply to the untarred GMP 5.0.4 source to turn it into the GMP 6.1.2 source. (We apply some other patches after unpacking already.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 02:41:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 02:41:05 -0000 Subject: [GHC] #13124: Template Haskell: Floating point literals that cannot be represented by rationals In-Reply-To: <045.3b1e3cade00998df210490cd104467e8@haskell.org> References: <045.3b1e3cade00998df210490cd104467e8@haskell.org> Message-ID: <060.8c083ad9266591ac601f1ebc9a946b3c@haskell.org> #13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => wontfix Comment: I'll close this as wontfix as it isn't really compatible with the way GHC treats floating literals internally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 02:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 02:41:51 -0000 Subject: [GHC] #8156: amd64 + in-tree gmp build broken In-Reply-To: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> References: <044.8d3c89c3b747f5cbec4467ee5ef43a21@haskell.org> Message-ID: <059.269ebad05c9db3250190137d6ed03c60@haskell.org> #8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #4022 #4366 | Differential Rev(s): #4374 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => closed * resolution: => fixed Comment: This was fixed by the new integer-gmp library in 7.10, which applies the following patch (part of `libraries/integer-gmp/gmp/gmpsrc.patch`) to build GMP with `-fPIC` unconditionally: {{{#!diff --- gmp-5.0.3/configure 2012-02-03 16:52:49.000000000 +0100 +++ gmpbuild/configure 2014-11-07 23:46:33.629758238 +0100 @@ -3937,8 +3937,8 @@ # cclist="gcc cc" -gcc_cflags="-O2 -pedantic" -gcc_64_cflags="-O2 -pedantic" +gcc_cflags="-O2 -pedantic -fPIC" +gcc_64_cflags="-O2 -pedantic -fPIC" cc_cflags="-O" cc_64_cflags="-O" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 07:34:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 07:34:09 -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.b32878636144311a744aeaa8d167bc2e@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by uznx): Just for the record, this bug can be reproduced by compiling Hackage's find-conduit 0.4.4 with GHC 8.0.1. find-conduit is the old version of conduit-find prior to a maintainer change, and prior to the workarounds to avoid this bug that have been incorporated into conduit-find. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:28:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:28:39 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.8c6c4763f6c40a1991dffd676f3adc1a@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2b64e926a628fb2a3710b0360123ea73331166fe/ghc" 2b64e926/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b64e926a628fb2a3710b0360123ea73331166fe" Apply the right substitution in ty-fam improvement Trac #13135 showed that we were failing to apply the correct substitution to the un-substituted tyvars during type-family improvement using injectivity. Specifically in TcInteractlinjImproveEqns we need to use instFlexiX. An outright bug, easy to fix. Slight refactoring along the way. The quantified tyars of the axiom are readily to hand; we don't need to take the free tyvars of the LHS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:40:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:40:36 -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.106511bbb8d32e8ae962e13a75980664@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 simonmar): This would be great - are you planning to do it? To avoid the indirect calls don't we need to specialise the hash table to the key type? There are at least two key types in use (strings and pointers). Also, couldn't we pull in a good third-party hash table implementation instead of writing our own? When I was working on the compact code I did try https://troydhanson.github.io/uthash/userguide.html but it was slower than the RTS hash table. I'm sure there are better ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:42:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:42:57 -0000 Subject: [GHC] #13142: Substitution invariant failure arising from OptCoercion In-Reply-To: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> References: <044.ecfc9b972ad01dc0799efafe7ed5df09@haskell.org> Message-ID: <059.643cbdaea620f56aacb4344919465337@haskell.org> #13142: Substitution invariant failure arising from OptCoercion -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Determinism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I wouldn't say the answer is ignoring the assert, if it is then what's the point of the assert? Correct; but it's a good way to get moving again. In this case, failure of the assertion probably won't lead to anything bad happening. It's not a reason to ignore the bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:46:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:46:07 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.0fedb446937299f79a6974cee39e4be4@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | 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 simonpj): * cc: simonmar (added) Comment: Adding `simonmar` who is king of finalisers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:51:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:51:40 -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.86e7fc3c753ee20b3c98fcfc74efb7ba@haskell.org> #13158: Pattern synonyms should use type annotation information when typechecking -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13159 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:52:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:52:00 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.0220f99ab65fd1e1de0068806ea8df30@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | 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 simonmar): Yes, this is technically a bug. We could have `runFinalizerBatch` catch and discard exceptions (or print them to stdout; it's really a bug if a finalizer throws an exception). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 08:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 08:59:36 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.7bdc7eb0cc08382b8e590bb2cda912c1@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T13135 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => dependent/should_fail/T13135 * status: new => closed * resolution: => fixed Comment: Thanks for reporting this, with such a nice test case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 09:00:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 09:00:08 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.af254ab544cf60195bb37cbb539a3226@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T13135 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge * milestone: => 8.0.3 Comment: I guess we could merge this to 8.03, if that happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 13:04:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 13:04:23 -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.70341f8e8b6ab837fe0dff6a8723a6b6@haskell.org> #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: infoneeded Priority: low | 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): Any package using cpphs on Windows should do. For example: {{{ git clone https://github.com/asr/pdfname.git cd pdfname stack init stack build }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 13:05:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 13:05:02 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.642bf3930134ef30a1318cae5a983941@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: 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): I'm open to ideas here. The tradeoff is that without the idle GC you don't get any deadlock detection (`BlockedOnDeadMVar` and friends) when the process is idle, so provided you're OK with that then it's fine to use `-I0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 14:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 14:16:50 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.a790a18d42acda422d9f96179a5f2042@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"729a5e452db530e8da8ca163fcd842faac6bd690/ghc" 729a5e45/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="729a5e452db530e8da8ca163fcd842faac6bd690" Don't quantify implicit type variables when quoting type signatures in TH Summary: A bug was introduced in GHC 8.0 in which Template Haskell-quoted type signatures would quantify _all_ their type variables, even the implicit ones. This would cause splices like this: ``` $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a idProxy x = x |]) ``` To splice back in something that was slightly different: ``` idProxy :: forall k proxy (a :: k). proxy a -> proxy a idProxy x = x ``` Notice that the kind variable `k` is now explicitly quantified! What's worse, this now requires the `TypeInType` extension to be enabled. This changes the behavior of Template Haskell quoting to never explicitly quantify type variables which are implicitly quantified in the source. There are some other places where this behavior pops up too, including class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports, and pattern synonynms (#13018), so I fixed those too. Fixes #13018 and #13123. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj, goldfire Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2974 GHC Trac Issues: #13018, #13123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 14:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 14:16:50 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.3ef21a12e705ba06ab0441922c60851b@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"729a5e452db530e8da8ca163fcd842faac6bd690/ghc" 729a5e45/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="729a5e452db530e8da8ca163fcd842faac6bd690" Don't quantify implicit type variables when quoting type signatures in TH Summary: A bug was introduced in GHC 8.0 in which Template Haskell-quoted type signatures would quantify _all_ their type variables, even the implicit ones. This would cause splices like this: ``` $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a idProxy x = x |]) ``` To splice back in something that was slightly different: ``` idProxy :: forall k proxy (a :: k). proxy a -> proxy a idProxy x = x ``` Notice that the kind variable `k` is now explicitly quantified! What's worse, this now requires the `TypeInType` extension to be enabled. This changes the behavior of Template Haskell quoting to never explicitly quantify type variables which are implicitly quantified in the source. There are some other places where this behavior pops up too, including class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports, and pattern synonynms (#13018), so I fixed those too. Fixes #13018 and #13123. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj, goldfire Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2974 GHC Trac Issues: #13018, #13123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 14:19:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 14:19:35 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.b3af0b74731da8496ba4b65d8d7fc924@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T13018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T13018 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 14:20:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 14:20:05 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.1479de10975a3b981432f671e16093fc@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T13123 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T13123 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 16:02:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 16:02:39 -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.acd5fab931306cb54aaf6df93fbcb0d6@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: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => phab:D3001 Comment: This still reproduces on GHC HEAD. @slyfox: Thanks for the profile, it was helpful to know where to look. phab:D3001 optimizes the hot `tickishContains` function a bit. I've experimented with this a bit and here's what I found: * 45 `()` literals generates 20929 `mkTick'` calls and 1371 `mkTick` calls. * 90 `()` literals generates 143074 `mkTick'` calls and 4746 `mkTick` calls. * 135 `()` literals generates 457594 `mkTick'` calls and 10146 `mkTick` calls. In the 45 case almost all of the calls come from `wrapTicks`, and out of these most of them (~20k) come from: {{{ wrapBind t (NonRec binder rhs) = NonRec binder (mkTick t rhs) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 17:01:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 17:01:49 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.c09357eabe7992b8f33bf23940177733@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T13123 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974, Wiki Page: | Phab:3002 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D2974 => Phab:D2974, Phab:3002 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 17:09:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 17:09:00 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.01ff45b12db405a4c9b38f67ef068e45@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3003 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D3003 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 17:41:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 17:41:53 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.48a94f398b56b91bc0a3b5dc347536a8@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- Reporter: erikd | Owner: dfeuer 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: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"596dece7866006d699969f775fd97bd306aad85b/ghc" 596dece/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="596dece7866006d699969f775fd97bd306aad85b" 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 Mon Jan 23 18:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 18:39:55 -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.2e80e06fe5934a58bc9c96d88e9dbf10@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): This issue also affects `-c` with multiple input files, which GHC builds in order, it seems, making it much easier to test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 19:17:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 19:17:48 -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.6e4cb928df6850a288d83dce18ab8521@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:"532c6ade49e9e8e7e98c35451058ba7e4ee7bb9c/ghc" 532c6ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="532c6ade49e9e8e7e98c35451058ba7e4ee7bb9c" Make tickishContains faster This just reorders some inequality checks to make the common case cheaper. The results are quite dramatic for #11095, but that's probably because something else is causing it to do too much work. Before (full https://phabricator.haskell.org/P136): ``` 13,589,495,832 bytes allocated in the heap ``` After (full https://phabricator.haskell.org/P137): ``` 7,885,575,872 bytes allocated in the heap ``` This is with `BuildFlavour = devel2`, so take it with a a grain of salt. For reference, with no `-g` I get: ``` 155,703,112 bytes allocated in the heap ``` so we're still quite a way off. Test Plan: harbormaster I still have to test locally Reviewers: austin, bgamari Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D3001 GHC Trac Issues: #11095 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 19:21:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 19:21:25 -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.405337d78317cbff79b222a84a599aa1@haskell.org> #13158: Pattern synonyms should use type annotation information when typechecking -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | 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 lexi.lambda): * related: #13159 => #13159, #11350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 19:47:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 19:47:50 -0000 Subject: [GHC] #12663: amazonka-ec2 fails to build with --split-objs In-Reply-To: <048.229708a11b5fa85980c94db5223a3842@haskell.org> References: <048.229708a11b5fa85980c94db5223a3842@haskell.org> Message-ID: <063.f45500e8ce44fdf713fc16066b10909d@haskell.org> #12663: amazonka-ec2 fails to build with --split-objs -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by joehillen): Looks like it is fixed in 8.0.2. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 19:48:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 19:48:44 -0000 Subject: [GHC] #12663: amazonka-ec2 fails to build with --split-objs In-Reply-To: <048.229708a11b5fa85980c94db5223a3842@haskell.org> References: <048.229708a11b5fa85980c94db5223a3842@haskell.org> Message-ID: <063.5c6afde3b8881ca2aadfaac558396a1e@haskell.org> #12663: amazonka-ec2 fails to build with --split-objs -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by joehillen): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 20:28:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 20:28:57 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.b02aeac4af2145ecc473e8ead3df7154@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | 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 alexbiehl): I don't know if this is that well defined. I have tried to implement this. Please take a look at https://github.com/alexbiehl/ghc/commit/fd9608ea93fc2389907b82c3fe540805d986c28e. Is this what you were talking about @simonpj? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 20:54:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 20:54:20 -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.4d2c97dae71e0086a79d0302833eba5d@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 simonpj): Is there something non-linear going on? (non-linear in program size that is.) Certainly sounds like it. If so, it'd be good to know what it is. We should try HARD to avoid anything worse than NlogN in program size. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 21:03:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 21:03:12 -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.d62502e4fc2133922f564e6a7935177f@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 bgamari): There is a `nubBy` in `Debug` which uses `tickishContains` which would make this N^2. This is likely the reason why the above patch made such a difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 21:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 21:35:56 -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.171a499c25fe13162dbca274730c19f8@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 niteria): I suspect (I have yet to read the paper!) that the resulting term has quadratic size. We're building: {{{ () : () : () : () : () : () : () : [] }}} which becomes: {{{ a = () : [] b = () : a c = () : b d = () : c e = () : d f = () : e g = () : f }}} We then construct ticks for each of `a..g`: {{{ ticks(a) = SrcLoc(a) ticks(b) = ticks(a) ++ SrcLoc(b) ticks(c) = ticks(b) ++ SrcLoc(c) ticks(d) = ticks(c) ++ SrcLoc(d) ticks(e) = ticks(d) ++ SrcLoc(e) ticks(f) = ticks(e) ++ SrcLoc(f) ticks(g) = ticks(f) ++ SrcLoc(g) -- the order of arguments here is important, -- we end up doing an equivalent of appending one element to a list -- we do that over all the expressions, for each SrcLoc }}} The reason my patch helped is this part of `mkTick'`: {{{ -- For annotations this is where we make sure to not introduce -- redundant ticks. | tickishContains t t2 -> mkTick' top rest e | tickishContains t2 t -> orig_expr | otherwise -> mkTick' top (rest . Tick t2) e }}} We almost always reach the `otherwise` case because the source locations are disjoint, so `tickishContains` is quite hot. Not only the result is quadratic, the function `wrapTicks` is quadratic as well: {{{ wrapTicks (Floats flag floats0) expr = (Floats flag floats1, expr') where (floats1, expr') = foldrOL go (nilOL, expr) floats0 -- ^ iterate over floats0 go (FloatTick t) (fs, e) = ASSERT(tickishPlace t == PlaceNonLam) (mapOL (wrap t) fs, mkTick t e) -- ^ map over fs, proportional in size to floats0 go other (fs, e) = (other `consOL` fs, e) -- ^ fs can grow proportional in size to floats0 wrap t (FloatLet bind) = FloatLet (wrapBind t bind) wrap t (FloatCase b r ok) = FloatCase b (mkTick t r) ok wrap _ other = pprPanic "wrapTicks: unexpected float!" (ppr other) wrapBind t (NonRec binder rhs) = NonRec binder (mkTick t rhs) wrapBind t (Rec pairs) = Rec (mapSnd (mkTick t) pairs) }}} Sorry I can't explain it better, the important point I believe is that the result has quadratic size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 21:37:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 21:37:42 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.8f1567df845c475303032b5677b362a6@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- 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 made several errors. First, here's a better test {{{ {-# 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 }}} I've made `g` recursive to guarantee a w/w split. And I've given it a type signature to avoid the overloading. With HEAD we get {{{ $wg_s2kz [InlPrag=[0], Occ=LoopBreaker] :: Bool -> Bool -> GHC.Prim.Int# -> GHC.Prim.Int# $wg_s2kz = \ (w_s2kp :: Bool) (w_s2kq :: Bool) (ww_s2ku :: GHC.Prim.Int#) -> case w_s2kp of { False -> case w_s2kq of { False -> $wg_s2kz GHC.Types.False GHC.Types.True ww_s2ku; True -> GHC.Prim.+# ww_s2ku 1# }; True -> case w_s2kq of { False -> $wg_s2kz GHC.Types.True GHC.Types.True ww_s2ku; True -> case f @ Int (GHC.Types.I# ww_s2ku) of wild_00 { } } } }}} Note the re-boxing of the argument `(I# ww_s2ku)`, in the call to `f`. Second, here is a patch that does the job {{{ diff --git a/compiler/coreSyn/CoreUnfold.hs b/compiler/coreSyn/CoreUnfold.hs index f7e4265..efae22c 100644 --- a/compiler/coreSyn/CoreUnfold.hs +++ b/compiler/coreSyn/CoreUnfold.hs @@ -54,7 +54,7 @@ import DataCon import Literal import PrimOp import IdInfo -import BasicTypes ( Arity ) +import BasicTypes ( Arity, InlineSpec(..), inlinePragmaSpec ) import Type import PrelNames import TysPrim ( realWorldStatePrimTy ) @@ -997,6 +997,9 @@ certainlyWillInline dflags fn_info -- See Note [certainlyWillInline: INLINABLE] do_cunf expr (UnfIfGoodArgs { ug_size = size, ug_args = args }) | not (null args) -- See Note [certainlyWillInline: be careful of thunks] + , case inlinePragmaSpec (inlinePragInfo fn_info) of + NoInline -> False -- NOINLINE; do not say certainlyWillInline! + _ -> True -- INLINE, INLINABLE, or nothing , let arity = length args , size - (10 * (arity + 1)) <= ufUseThreshold dflags = Just (fn_unf { uf_src = InlineStable diff --git a/compiler/stranal/WorkWrap.hs b/compiler/stranal/WorkWrap.hs index d50bb22..9a0ccc5 100644 --- a/compiler/stranal/WorkWrap.hs +++ b/compiler/stranal/WorkWrap.hs @@ -283,12 +283,6 @@ tryWW :: DynFlags -- if two, then a worker and a -- wrapper. tryWW dflags fam_envs is_rec fn_id rhs - | isNeverActive inline_act - -- No point in worker/wrappering if the thing is never inlined! - -- Because the no-inline prag will prevent the wrapper ever - -- being inlined at a call site. - = return [ (new_fn_id, rhs) ] - | Just stable_unf <- certainlyWillInline dflags fn_info = return [ (fn_id `setIdUnfolding` stable_unf, rhs) ] -- See Note [Don't w/w INLINE things] @@ -305,7 +299,6 @@ tryWW dflags fam_envs is_rec fn_id rhs where fn_info = idInfo fn_id - inline_act = inlinePragmaActivation (inlinePragInfo fn_info) (wrap_dmds, res_info) = splitStrictSig (strictnessInfo fn_info) new_fn_id = zapIdUsedOnceInfo (zapIdUsageEnvInfo fn_id) }}} There are two components * Remove the `isNeverActtive` branch in `tryWW`, as described above * Make `certainlyWillInline` return `False` for any NOINLINE thing. I hadn't realised that this would be necessary but it's obviously true that a NOINLINE thing shouldn't reply `True` to `certainlyWillInline`. Now we get no re-boxing in the example. Would you like to try that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:04:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:04:21 -0000 Subject: [GHC] #13169: Documentation for CoreMonad.getAnnotations Message-ID: <045.0290881c8aac5d4cef13b6a813755b7d@haskell.org> #13169: Documentation for CoreMonad.getAnnotations -------------------------------------+------------------------------------- Reporter: abakst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for `getAnnotations` in `CoreMonad` is a bit unclear. In particular, the documentation could be improved by indicating that the returned `UniqFM` is keyed off of the `Unique` corresponding to an `AnnTarget`: That is, to look up the annotations on `x`, it seems one should call `getAnnotations` on either `ModuleTarget x` or `NamedTarget x` (if my understanding of how this all works is correct, that is). I stumbled across this by trying to look up the annotations on module `m` using the key `getUnique m`. This was incorrect as the annotation is stored on a unique *derived* from `getUnique m` (which wasn't indicated in the documentation). Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:18:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:18:49 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD Message-ID: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: highest | 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 HEAD hits a Core Lint error on this simple module: {{{#!hs module Fold where f :: Int -> Bool f x = y == 2 || y == 3 where y = -x }}} when compiling with `-O -dcore-lint`. This causes the Harbormaster build to fail on ia32. This doesn't effect 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:20:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:20:21 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.db41f71670136c2afb52a945c1d9abb0@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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 rwbarton): * owner: => rwbarton Comment: It seems to be caused by https://phabricator.haskell.org/D2762 not reordering the mapped cases. Investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:25:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:25:54 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.08f324c814395e10348d970be5615838@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): For the record, the core lint failure looks like {{{ *** Core Lint errors : in result of Simplifier *** : warning: In a case alternative: (I# x_a1Nt :: Int#) Case expression with badly-ordered alternatives case x_a1Nt of wild_Xq { __DEFAULT -> let { wild_Xq :: Int# [LclId, Unf=OtherCon []] wild_Xq = negateInt# x_a1Nt } in False; -2# -> let { wild_Xq :: Int# [LclId, Unf=OtherCon []] wild_Xq = 2# } in True; -3# -> let { wild_Xq :: Int# [LclId, Unf=OtherCon []] wild_Xq = 3# } in True } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:44:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:44:53 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.afaab634fafecc963c6fe132b0018cfc@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T13135 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Saulzar): Great job, glad it was useful. I thought I'd try simplifying the syntactic library with new ghc features and this was a bit of a stumbling block, cheers! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:51:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:51:43 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.d8a30eacca2f2eed4d1657698768f9c5@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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: | simplCore/should_compile/T13170 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3008 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => simplCore/should_compile/T13170 * differential: => Phab:D3008 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 22:59:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 22:59:41 -0000 Subject: [GHC] #13171: panic on negative literal in case on Word Message-ID: <047.15bfc176b50e0ce287f07fd3708d2096@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.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 module Case where f :: Word -> Word f n = case n of -1 -> 2 _ -> 3 }}} {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170119 for x86_64-unknown-linux): ASSERT failed! -1 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1182:22 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/Literal.hs:223:75 in ghc:Literal 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/utils/Outputable.hs:1180:5 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/Literal.hs:223:75 in ghc:Literal Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Doesn't happen in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 23:08:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 23:08:15 -0000 Subject: [GHC] #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds Message-ID: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program should output 2, but in 8.1 with `-O` enabled it outputs 3. The problem is with the way that scrutinee constant folding rewrites the case. {{{#!hs f :: Word -> Word f n = case n+1 of 0 -> 2 _ -> 3 {-# NOINLINE f #-} main = print (f (-1)) }}} Core with 8.1 and `-O`: {{{ f [InlPrag=NOINLINE] :: Word -> Word [GblId, Arity=1, Caf=NoCafRefs, Str=m] f = \ (n_ay2 :: Word) -> case n_ay2 of { GHC.Types.W# x#_a1SL -> case x#_a1SL of { __DEFAULT -> lvl_r4lD; -1## -> lvl1_r4mD } } }}} Apparently `-1##` isn't okay: it needs to be `9223372036854775807##`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 23:23:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 23:23:09 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.ee178f4eae082ef79850ab3b2e94ff2c@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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: | simplCore/should_compile/T13170 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3008 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Incidentally, the failure in {{{#!hs isSigIntQuit n = sig == sigINT || sig == sigQUIT where sig = fromIntegral (-n) }}} only showed up on a 32-bit system because `sig :: CInt` is 32 bits, and so on a 64-bit system there is also a `GHC.Prim.narrow32Int#` in the case scrutinee (from the implementation of `negate` for `CInt`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 23:58:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 23:58:22 -0000 Subject: [GHC] #13173: Investigate old comment at the top of SrcLoc Message-ID: <049.af322c28fe17d2cc0fdfe3a2a2bc01fc@haskell.org> #13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a comment at the top of `SrcLoc` which says {{{ {-# OPTIONS_GHC -fno-omit-interface-pragmas #-} -- Workaround for Trac #5252 crashes the bootstrap compiler without -O -- When the earliest compiler we want to boostrap with is -- GHC 7.2, we can make RealSrcLoc properly abstract }}} This is a well-defined small task so I will mark it for newcomers. 1. Try to work out what the pragma is meant to do by reading #5252 2. Work out whether we can now make `RealSrcLoc` "properly abstract" (if it is not already) 3. Remove or update this comment and pragma. 4. Pray it doesn't break the whole compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 23 23:59:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jan 2017 23:59:03 -0000 Subject: [GHC] #13092: family instance consistency checks are too pessimistic In-Reply-To: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> References: <047.4d30fd1afb028f7e4df23e05e7e42e6e@haskell.org> Message-ID: <062.979e6112aa316951c50196292750cade@haskell.org> #13092: family instance consistency checks are too pessimistic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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): Phab:D2992 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the Phab is fine, but here's a possible thought for improvement to `checkFamInstConsistency`. Currently it does an all-pairs enumeration, and filters out pairs that are already known consistent. That sounds like enumerating a large set and then filtering it. What about this. Take just two imported modules A and B, with `dep_finsts` dA and dB resp. So we know that `A + dA` is consistent and `B + dB` is consistent. What extra parirwise checks do we need to make to ensure that `uAB` is consistent, where {{{ uAB = A + dA + B + dB }}} (I'm using `+` for set union.) Well, define {{{ iAB = (A + dA) `intersect` (B + dB) }}} so that `iAB` is the intersection; certainly it is consistent all of `uAB`. Now define {{{ xA = (A + dA) - iAB xB = (B + dB) - iAB }}} If we check all the pairs with one from `xA` and one from `xB` we are done. So check those and form the union `uAB`. Now continue by adding in one more module, and keep doing that a time. The bigger the intersection the better. I'm not certain that is better, but it smells better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 00:16:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 00:16:41 -0000 Subject: [GHC] #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds In-Reply-To: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> References: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> Message-ID: <062.12c9f4984dc0113d8ab12a9dd1e8c7a5@haskell.org> #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch 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): Phab:D3009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D3009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 00:20:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 00:20:14 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.4fc72a5a4d3e3a6e4582d6df48368c8b@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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: | simplCore/should_compile/T13170 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3008 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It seems to be caused by ​https://phabricator.haskell.org/D2762 not reordering the mapped cases That looks absolutely right. You need to re-sort the alternatives to ensure thay are still in ascending order. See `CoreSyn` ``` -- 3. The remaining cases are in order of increasing -- tag (for 'DataAlts') or -- lit (for 'LitAlts'). -- This makes finding the relevant constructor easy, -- and makes comparison easier too. ``` Well spotted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 02:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 02:20:55 -0000 Subject: [GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note Message-ID: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> #13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ghc/libraries/base/GHC/IO/Unsafe.hs` contains the following note: {{{ -- Note [unsafeDupablePerformIO is NOINLINE] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Why do we NOINLINE unsafeDupablePerformIO? See the comment with -- GHC.ST.runST. Essentially the issue is that the IO computation -- inside unsafePerformIO must be atomic: it must either all run, or -- not at all. If we let the compiler see the application of the IO -- to realWorld#, it might float out part of the IO. }}} However, `unsafeDupablePerformIO` does not actually have a `NOINLINE` pragma. So either the note is out of date and should be removed/modified, or someone messed up the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 02:40:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 02:40:43 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.6c559b91b2b7d3a007a167bb4fd8fbbd@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): {{{#!hs e1 :: (f a -> b) -> (g a -> b) -> (f :+: g) a -> b e1 f _ (L1 l) = f l e1 _ f (R1 r) = f r fst1 :: (f :*: g) a -> f a fst1 (l :*: _) = l snd1 :: (f :*: g) a -> g a snd1 (_ :*: r) = r }}} are defined in [https://hackage.haskell.org/package/one-liner-0.7/docs/src /Generics-OneLiner-Internal.html one-liner] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:10:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:10:32 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" Message-ID: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Nowhere in the documentation is it clearly stated which classes can be derived (assuming extensions as necessary) by GHC's "deriving" mechanism. As determined by reading the sources, this appears to be - Bounded, Enum, Eq, Ix, Ord, Read, Show, Functor, Foldable, Traversable, Generic, Generic1, Data, Lift. This was discussed on haskell-cafe -- see https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125379.html. PS: I would be willing to fix this myself, if only I knew *where* to insert that information so that it is easily ''findable''! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:19:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:19:26 -0000 Subject: [GHC] #13176: Deprecate the realWorld# Message-ID: <045.509c344604cc28838eb26ce21b952d2f@haskell.org> #13176: Deprecate the realWorld# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.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: -------------------------------------+------------------------------------- There's some about that's intended to prevent problems with the real world. What if we deprecate `realWorld#`? People will still be able to shoot themselves in the foot by ''defining'' `realWorld#` in terms of `runRW#`, but a warning in the documentation should hopefully be sufficient to prevent that. Another, considerably more invasive, option might be to use something like {{{#!hs runST# :: (forall s . State# s -> o) -> o data RealWorld :: * -> * runIO# :: (forall i . State# (RealWorld i) -> o) -> o }}} This would (I believe) provide a much stronger guarantee that the real world can't escape. But it would probably break considerably more code, so I doubt it would be worth the trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:20:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:20:03 -0000 Subject: [GHC] #13176: Deprecate the realWorld# In-Reply-To: <045.509c344604cc28838eb26ce21b952d2f@haskell.org> References: <045.509c344604cc28838eb26ce21b952d2f@haskell.org> Message-ID: <060.ba1282a1fd7c20423728b1d97ac1c9ab@haskell.org> #13176: Deprecate the realWorld# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -1,3 +1,3 @@ - There's some about that's intended to prevent problems with the real - world. What if we deprecate `realWorld#`? People will still be able to - shoot themselves in the foot by ''defining'' `realWorld#` in terms of + There's some messy code about that's intended to prevent problems with the + real world. What if we deprecate `realWorld#`? People will still be able + to shoot themselves in the foot by ''defining'' `realWorld#` in terms of New description: There's some messy code about that's intended to prevent problems with the real world. What if we deprecate `realWorld#`? People will still be able to shoot themselves in the foot by ''defining'' `realWorld#` in terms of `runRW#`, but a warning in the documentation should hopefully be sufficient to prevent that. Another, considerably more invasive, option might be to use something like {{{#!hs runST# :: (forall s . State# s -> o) -> o data RealWorld :: * -> * runIO# :: (forall i . State# (RealWorld i) -> o) -> o }}} This would (I believe) provide a much stronger guarantee that the real world can't escape. But it would probably break considerably more code, so I doubt it would be worth the trouble. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:40:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:40:14 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.e35f3712a8df796f7a3328653c48a40d@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Please consider these functions from a [http://stackoverflow.com/a/25817530/165806 StackOverflow answer] {{{#!hs liftO :: (Functor f, Applicative g) => f ~> Compose f g liftO = Compose . fmap pure liftI :: Applicative f => g ~> Compose f g liftI = Compose . pure hoistO :: f ~> f' -> Compose f g ~> Compose f' g hoistO eta = Compose . eta . getCompose hoistI :: Functor f => g ~> g' -> Compose f g ~> Compose f g' hoistI eta = Compose . fmap eta . getCompose }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:44:56 -0000 Subject: [GHC] #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds In-Reply-To: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> References: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> Message-ID: <062.a42fde5e71e0027b1b38ae706a738f28@haskell.org> #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch 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): Phab:D3009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"53e2e70a477896d57059b5f12147b69d22a2e2e0/ghc" 53e2e70a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="53e2e70a477896d57059b5f12147b69d22a2e2e0" Ensure that scrutinee constant folding wraps numbers Test Plan: T13172 Reviewers: rwbarton, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3009 GHC Trac Issues: #13172 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:44:56 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented In-Reply-To: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> References: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> Message-ID: <064.e16f8c2f0e69d1555062fe1ed05a2dd4@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | 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 Ben Gamari ): In [changeset:"a8c81f3c102988e0f4216b7cb5fec7958e60b4e4/ghc" a8c81f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8c81f3c102988e0f4216b7cb5fec7958e60b4e4" Document -fspecialise-aggressively Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3007 GHC Trac Issues: #12979 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:44:56 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.55ab17a567009abc9ceb708873119350@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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: | simplCore/should_compile/T13170 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3008 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"abaa6815e6435ed29ad121b5e59fc017a1d3e836/ghc" abaa6815/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abaa6815e6435ed29ad121b5e59fc017a1d3e836" Re-sort case alternatives after scrutinee constant folding (#13170) Commit d3b546b1a605 added a "scrutinee constant folding" pass that rewrites a case expression whose scrutinee is an expression like x +# 3#. But case expressions are supposed to have their alternatives in sorted order, so when the scrutinee is (for example) negateInt# x#, we need to re-sort the alternatives after mapping their values. This showed up as a core lint failure when compiling System.Process.Posix: isSigIntQuit n = sig == sigINT || sig == sigQUIT where sig = fromIntegral (-n) Data.List.sortBy is supposed to be linear-time on sorted or reverse-sorted input, so it is probably not worth doing anything more clever than this. Test Plan: Added a new test T13170 for the above case. Reviewers: austin, hsyl20, simonpj, bgamari Reviewed By: hsyl20, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3008 GHC Trac Issues: #13170 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 03:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 03:44:56 -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.bcae2d762ce832e50ff6b3e6267f04dc@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:"8f49f6de2121541d3bf8254abb402b6e7bfee8fb/ghc" 8f49f6d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f49f6de2121541d3bf8254abb402b6e7bfee8fb" Add a failing test for #13102 Test Plan: harbormaster Reviewers: austin, ezyang, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3005 GHC Trac Issues: #13102 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 04:02:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 04:02:02 -0000 Subject: [GHC] #13170: Core Lint error on git HEAD In-Reply-To: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> References: <047.dfb09c6531fb3150ebb9f9edb4794271@haskell.org> Message-ID: <062.c37254556c1bea724c5d78f6b772bca1@haskell.org> #13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: rwbarton 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: | simplCore/should_compile/T13170 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3008 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 Tue Jan 24 04:02:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 04:02:12 -0000 Subject: [GHC] #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds In-Reply-To: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> References: <047.e9d20865c76517ec5a5a29c3856ee54c@haskell.org> Message-ID: <062.af8b1f9965059ba14a6cd40909911e05@haskell.org> #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: 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:D3009 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 Tue Jan 24 04:15:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 04:15:28 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted unit and void Message-ID: <051.47ebb92305025f856dac567302c0becb@haskell.org> #13177: Give Data.Functor.* its lifted unit and void -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- `GHC.Generics` has {{{#!hs data U1 a = U1 data V1 a }}} They are simple but why are they not present in the `Data.Functor` hierarchy along with functions like (from [https://hackage.haskell.org/package/one-liner-0.7/docs/src/Generics- OneLiner-Internal.html one-liner]) {{{#!hs absurd :: V1 a -> b absurd = \case }}} Packages like [https://hackage.haskell.org/package/linear linear] provide basically the same lifted functors {{{#!hs data V0 a = V0 newtype V1 a = V1 a }}} if they or those from `GHC.Generics` should be preferred it could be added to the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 04:17:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 04:17:08 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted unit and void In-Reply-To: <051.47ebb92305025f856dac567302c0becb@haskell.org> References: <051.47ebb92305025f856dac567302c0becb@haskell.org> Message-ID: <066.1db0615dabefbeaa5f4f642860bb2274@haskell.org> #13177: Give Data.Functor.* its lifted unit and void -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -18,2 +18,2 @@ - Packages like [https://hackage.haskell.org/package/linear linear] provide - basically the same lifted functors + The package [https://hackage.haskell.org/package/linear linear] provides + the lifted unit functor @@ -22,2 +22,1 @@ - data V0 a = V0 - newtype V1 a = V1 a + data V0 a = V0 New description: `GHC.Generics` has {{{#!hs data U1 a = U1 data V1 a }}} They are simple but why are they not present in the `Data.Functor` hierarchy along with functions like (from [https://hackage.haskell.org/package/one-liner-0.7/docs/src/Generics- OneLiner-Internal.html one-liner]) {{{#!hs absurd :: V1 a -> b absurd = \case }}} The package [https://hackage.haskell.org/package/linear linear] provides the lifted unit functor {{{#!hs data V0 a = V0 }}} if they or those from `GHC.Generics` should be preferred it could be added to the documentation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 04:19:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 04:19:52 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted void and unit (was: Give Data.Functor.* its lifted unit and void) In-Reply-To: <051.47ebb92305025f856dac567302c0becb@haskell.org> References: <051.47ebb92305025f856dac567302c0becb@haskell.org> Message-ID: <066.859f3694afd65002ab3650a68c8e9f0e@haskell.org> #13177: Give Data.Functor.* its lifted void and unit -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -4,0 +4,1 @@ + data V1 a @@ -5,1 +6,0 @@ - data V1 a @@ -26,1 +26,1 @@ - to the documentation. + to the documentation New description: `GHC.Generics` has {{{#!hs data V1 a data U1 a = U1 }}} They are simple but why are they not present in the `Data.Functor` hierarchy along with functions like (from [https://hackage.haskell.org/package/one-liner-0.7/docs/src/Generics- OneLiner-Internal.html one-liner]) {{{#!hs absurd :: V1 a -> b absurd = \case }}} The package [https://hackage.haskell.org/package/linear linear] provides the lifted unit functor {{{#!hs data V0 a = V0 }}} if they or those from `GHC.Generics` should be preferred it could be added to the documentation -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 04:20:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 04:20:23 -0000 Subject: [GHC] #13178: Generalize type of runRW# Message-ID: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Currently, we have {{{#!hs runRW# :: (State# RealWorld -> (# State# RealWorld, o #)) -> (# State# RealWorld, o #) }}} where `o` is open-kinded. This type is a bit annoying, because `runRW#` is very often used in contexts where we want to discard the state token. I think it should be easy to generalize, however: {{{#!hs runRW# :: (State# RealWorld -> o) -> o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 05:08:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 05:08:57 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.b83a8f546837c156b3468f4361e47c19@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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): Phab:D3012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => dfeuer * differential: => Phab:D3012 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 05:09:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 05:09:48 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.7864d48f0ac85b455afd3d058ab485c2@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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:D3012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 05:27:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 05:27:40 -0000 Subject: [GHC] #13179: Levity-polymorphic data types Message-ID: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> #13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12708 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know if this belongs as a part of [https://github.com/ghc- proposals/ghc-proposals/pull/30 levity-polymorphic type classes] (#12708) but many data types can be made levity-polymorphic, some have just been added to base: {{{#!hs -- Sum Array# Array# :: Type -> Type data Product :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where Pair :: f a -> g a -> (Product f g) a -- Sum Array# Array# :: Type -> Type data Sum :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where InL :: f a -> (Sum f g) a InR :: g a -> (Sum f g) a -- Compose Array# [] :: Type -> Type data Compose :: forall rep. (b -> TYPE rep) -> (a -> b) -> (a -> Type) where Compose :: f (g a) -> (Compose f g) a }}} Can you think of other examples? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 05:28:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 05:28:06 -0000 Subject: [GHC] #13179: Levity-polymorphic data types In-Reply-To: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> References: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> Message-ID: <066.23921682c093cc05b56a654f19237518@haskell.org> #13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -7,2 +7,1 @@ - - -- Sum Array# Array# :: Type -> Type + -- Product Array# Array# :: Type -> Type New description: I don't know if this belongs as a part of [https://github.com/ghc- proposals/ghc-proposals/pull/30 levity-polymorphic type classes] (#12708) but many data types can be made levity-polymorphic, some have just been added to base: {{{#!hs -- Product Array# Array# :: Type -> Type data Product :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where Pair :: f a -> g a -> (Product f g) a -- Sum Array# Array# :: Type -> Type data Sum :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where InL :: f a -> (Sum f g) a InR :: g a -> (Sum f g) a -- Compose Array# [] :: Type -> Type data Compose :: forall rep. (b -> TYPE rep) -> (a -> b) -> (a -> Type) where Compose :: f (g a) -> (Compose f g) a }}} Can you think of other examples? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 07:58:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 07:58:36 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.bdb2ce1c779eb29615edaae6f66cb5e7@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeiea): I checked that the problem remains on ghc 8.0.2, and also found similar error message when building ghc-mod. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 07:59:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 07:59:18 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.561ca61693d8acaa20c32fd203f2da25@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jeiea): * status: closed => new * resolution: duplicate => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 08:41:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 08:41:17 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.c1b92532743210afdc857297e9dc8890@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeiea): It's strange, Building ghc-mod succeeds on ghc-8.0.1 but fails on ghc-8.0.2. My attached file consistently fails on both version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 09:41:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 09:41:22 -0000 Subject: [GHC] #13180: Confusing error when hs-boot abstract data implemented using synonym Message-ID: <045.b9c6842f30daccdc427e781dc0928bbc@haskell.org> #13180: Confusing error when hs-boot abstract data implemented using synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: 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: -------------------------------------+------------------------------------- This example is a little goofy (that's why I've marked it low priority), but here goes: {{{ -- A.hs-boot module A where data T f :: T -> T -- B.hs module B(f) where import {-# SOURCE #-} A -- A.hs module A(T, f) where import qualified B type T = Int f :: T -> T f x = B.f x }}} When compiled, we get a very interesting error: {{{ ezyang at sabre:~$ ghc-head --make A.hs -fforce-recomp [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs-boot:2:1: error: Type constructor ‘T’ has conflicting definitions in the module and its hs-boot file Main module: type T = Int Boot file: abstract T | 2 | data T | ^^^^^^ A.hs-boot:3:1: error: Identifier ‘f’ has conflicting definitions in the module and its hs-boot file Main module: f :: T -> T Boot file: f :: T -> T The two types are different | 3 | f :: T -> T | ^^^^^^^^^^^ }}} The first error is legitimate, but the second is puzzling. I believe the problem has to do with the fact that when we load the hs-boot file for checking, we knot-tie it against itself. Thus, the T referenced in "Boot file" is the one WITHOUT the type synonym unfolding, while the main module *does* have the type synonym unfolding. Pretty-printing is horribly confusing in these situations, so it would be nice if we could give some better guidance here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 09:53:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 09:53:37 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.4071796eb1a3518d90bd1a3f265de0d8@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > PS: I would be willing to fix this myself, if only I knew *where* to insert that information so that it is easily findable! Thank you! But you are the best person to say where you'd expect to find it, because presumably you looked :-). I'd love a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 11:14:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 11:14:29 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.15f40a6acb3f7a041038e98c9ea832f5@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | 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 alexbiehl): I have refined the above patch in https://github.com/alexbiehl/ghc/commit/e29f88b5d952f2f40f68e2bb49f051b6684d2686 and ran `./validate --testsuite-only --fast` on it It result in longer compile time (about 27-35%) for `T1969` and `T3294` I have no clue why. But both `haddock.base' and `haddock.Cabal` show ~30% less allocations and `T9203' even 57%. I think this is nice. I hope I am on the right track here. {{{ Unexpected stat failures: /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/compiler/T1969.run T1969 [stat not good enough] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/compiler/T5631.run T5631 [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/compiler/T3294.run T3294 [stat not good enough] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/haddock/haddock.base.run haddock.base [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/should_run/T5205.run T5205 [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/should_run/T9203.run T9203 [stat too good] (normal) peak_megabytes_allocated value is too high: Expected T1969(normal) peak_megabytes_allocated: 68 +/-20% Lower bound T1969(normal) peak_megabytes_allocated: 54 Upper bound T1969(normal) peak_megabytes_allocated: 82 Actual T1969(normal) peak_megabytes_allocated: 87 Deviation T1969(normal) peak_megabytes_allocated: 27.9 % max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 17285216 +/-15% Lower bound T1969(normal) max_bytes_used: 14692433 Upper bound T1969(normal) max_bytes_used: 19877999 Actual T1969(normal) max_bytes_used: 23225104 Deviation T1969(normal) max_bytes_used: 34.4 % *** unexpected stat test failure for T1969(normal) max_bytes_used value is too high: Expected T3294(normal) max_bytes_used: 52992688 +/-20% Lower bound T3294(normal) max_bytes_used: 42394150 Upper bound T3294(normal) max_bytes_used: 63591226 Actual T3294(normal) max_bytes_used: 64107552 Deviation T3294(normal) max_bytes_used: 21.0 % *** unexpected stat test failure for T3294(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5631(normal) bytes allocated: 1077429456 +/-5% Lower bound T5631(normal) bytes allocated: 1023557983 Upper bound T5631(normal) bytes allocated: 1131300929 Actual T5631(normal) bytes allocated: 1006121416 Deviation T5631(normal) bytes allocated: -6.6 % *** unexpected stat test failure for T5631(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.base(normal) bytes allocated: 32855223200 +/-5% Lower bound haddock.base(normal) bytes allocated: 31212462040 Upper bound haddock.base(normal) bytes allocated: 34497984360 Actual haddock.base(normal) bytes allocated: 22651400376 Deviation haddock.base(normal) bytes allocated: -31.1 % *** unexpected stat test failure for haddock.base(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.Cabal(normal) bytes allocated: 25478853176 +/-5% Lower bound haddock.Cabal(normal) bytes allocated: 24204910517 Upper bound haddock.Cabal(normal) bytes allocated: 26752795835 Actual haddock.Cabal(normal) bytes allocated: 17772058640 Deviation haddock.Cabal(normal) bytes allocated: -30.2 % bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5205(normal) bytes allocated: 56208 +/-5% Lower bound T5205(normal) bytes allocated: 53397 Upper bound T5205(normal) bytes allocated: 59019 Actual T5205(normal) bytes allocated: 53360 Deviation T5205(normal) bytes allocated: -5.1 % *** unexpected stat test failure for T5205(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9203(normal) bytes allocated: 95451192 +/-5% Lower bound T9203(normal) bytes allocated: 90678632 Upper bound T9203(normal) bytes allocated: 100223752 Actual T9203(normal) bytes allocated: 40617752 Deviation T9203(normal) bytes allocated: -57.4 % *** unexpected stat test failure for T9203(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 11:27:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 11:27:47 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.760a0bbd60f48398250f242501123bf9@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | 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 mpickering): Perhaps you could push a branch so that gipeda can pick it up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 12:08:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 12:08:19 -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.66cf026f70ebf80d0612da63d29dd9f6@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: | -------------------------------------+------------------------------------- Description changed by simonmar: @@ -6,4 +6,4 @@ - used for anything particularly performance critical other than `StablePtr` - operations. However, it has since become the bottleneck when compacting - with sharing, to the point that compacting without sharing is around 10x - faster and is thus the default. + used for anything particularly performance critical other than + `StableName` operations. However, it has since become the bottleneck when + compacting with sharing, to the point that compacting without sharing is + around 10x faster and is thus the default. New description: The RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StableName` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 12:23:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 12:23:28 -0000 Subject: [GHC] #13121: Investigate whether uploading build artifacts from harbormaster would be usful In-Reply-To: <049.7c32dc32e9d5ea84423377cf9fb4523c@haskell.org> References: <049.7c32dc32e9d5ea84423377cf9fb4523c@haskell.org> Message-ID: <064.0950d7fc9b189b9b8928fb1a8e77f1c5@haskell.org> #13121: Investigate whether uploading build artifacts from harbormaster would be usful -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 12:24:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 12:24:31 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented In-Reply-To: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> References: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> Message-ID: <064.80f20fbd154054dcad315701d63bf8c3@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 14:52:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 14:52:02 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.9469edea620b9cf33cb486cb6b2ed2f4@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carette): Unfortunately I 'looked' via Google. I expected to find it that way... Once the information is somewhere, I will then expect that that will indeed work. But, in the meantime, I am still at a loss as to where to put it. One of the problems is that when you search for "GHC" and "deriving", the principal hits are to section 7.5 of the manual (https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/deriving.html) which documents the extensions to this mechanism. If you dig really (really!) hard, you eventually find section 4.3.3 of the Haskell 98 report (https://www.haskell.org/onlinereport/decls.html#derived-decls) which documents "deriving" (the 2010 report's 4.3.3 is essentially identical). But Google doesn't seem to like that much, so it doesn't show up. But the list in those reports is not the same as the list above! So I am still at a loss as to where to put this. GHC's own documentation does not define "deriving" (because the Haskell reports already do), which would have been my first thought. So maybe in 7.5 somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 15:15:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 15:15:57 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.0c4cd5e84bf7b3d087eeff88b9e09d95@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: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, yesterday dalaing_ stopped by `#ghc` and expressed interest in picking the `pretty` refactoring necessary for this ticket (comment:60). I'll try to make sure he subscribes to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 15:31:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 15:31:50 -0000 Subject: [GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't In-Reply-To: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> References: <050.71fc4ea9ccf39bafa5b818bdfcc77fe6@haskell.org> Message-ID: <065.7ba62095d2ea4c6c479fea26a6001a14@haskell.org> #13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T13123 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2974, Wiki Page: | Phab:3002 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9fd87ef8a16fbbce35205ae63d75d239bb575ccc/ghc" 9fd87ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9fd87ef8a16fbbce35205ae63d75d239bb575ccc" Don't put foralls in front of TH-spliced GADT constructors that don't need them Summary: It turns out that D2974 broke this program (see https://phabricator.haskell.org/rGHC729a5e452db5#58801): ```lang=haskell {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import GHC.Exts (Constraint) $([d| data Dec13 :: (* -> Constraint) -> * where MkDec13 :: c a => a -> Dec13 c |]) ``` This was actually due to a long-standing bug in `hsSyn/Convert` that put unnecessary `forall`s in front of GADT constructors that didn't have any explicitly quantified type variables. This cargo-cults the code in `Convert` that handles `ForallT` and adapts it to `ForallC`. Fixes #13123 (for real this time). Test Plan: make test TEST=T13123 Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3002 GHC Trac Issues: #13123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 15:36:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 15:36:36 -0000 Subject: [GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note In-Reply-To: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> References: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> Message-ID: <060.c2fb390ccc21dfa3a764c283f1967bb6@haskell.org> #13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oops, I deleted the reference to the note in https://phabricator.haskell.org/D1103, but failed to remove the note itself. Same story with the note `[unsafeDupablePerformIO has a lazy RHS]`. The lack of NOINLINE is okay because `runRW#` is NOINLINE. I'm not sure what the story about strictness was though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 15:41:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 15:41:08 -0000 Subject: [GHC] #13181: Introduce GHC.TypeNats module with natVal Message-ID: <045.1d8af59ec2de44bad9e961bf2587592f@haskell.org> #13181: Introduce GHC.TypeNats module with natVal -------------------------------------+------------------------------------- Reporter: phadej | Owner: phadej Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See [https://mail.haskell.org/pipermail/libraries/2017-January/027615.html libraries thread] Currently we have in the GHC.TypeLits module {{{ natVal :: forall n proxy. KnowNat n => proxy n -> Integer }}} However, the result integer is never negative. Numeric.Natural module is in base since base-4.8.0.0. --- I propose that we introduce new module GHC.TypeNats with natVal and natVal' {{{ natVal :: forall n proxy. KnownNat n => proxy n -> Natural }}} and {{{ natVal' :: forall n. KnownNat n => Proxy# n -> Natural }}} and other KnownNat related terms and type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 17:31:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 17:31:53 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.efa226879dcfbab47637b4c5678a22b4@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thank you for the report. So you're correct in that the list of //stock// derivable classes is not so Google-able (where `stock` is terminology that I use in the upcoming `DerivingStrategies` GHC extension, documented [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies here]). That `DerivingStrategies` wiki page information does need to be in a more public location, I admit. The users' guide actually //does// list all of the stock derivable classes that are available via GHC extensions in http://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html #deriving-instances-of-extra-classes-data-etc. But we don't currently list the stock derivable classes that were already mentioned in the Haskell Report (`Bounded`, `Enum`, `Ix`, `Eq`, `Ord`, `Read`, and `Show`). If I recapped those classes in that section of the users' guide, would that work for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 17:47:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 17:47:25 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.b08e769896885a03405adb6e15c9dc58@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Can I give you some honest advice, Iceland_jack? I barely have any idea what this proposal is even about anymore. That's because you have been clogging this thread with clutter that doesn't pertain to the original proposal. Your argument doesn't become more convincing the more definitions you throw at us - in fact, it has quite the opposite effect! This thread is now so overloaded with tangentially related cruft that I suspect no one except the most masochistic lurkers will dare attempt to read it. Sorry if that was harsh, but I feel that it needed to be said. Proposals are best kept to a small, self-contained unit of information that is easily digestible. You did the right thing by starting a libraries mailing list [https://mail.haskell.org/pipermail/libraries/2016-December/027489.html discussion] about `(||||)` and `(&&&&)` (and //only// `(||||)` and `(&&&&)`)! In the particular case of this proposal, it hasn't seemed to have reached a consensus on the naming - and that's fine! All you need to do is figure out names that a majority of the community can agree with, and argue convincingly for it. These other functions that you've put above are just distracting from the main thing you're trying to advocate for. Perhaps small subsets of them could be interesting proposals on their own. If so, start separate libraries discussions for them! But please don't bog down your own proposal by including everything under the sun. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 17:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 17:53:08 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted void and unit In-Reply-To: <051.47ebb92305025f856dac567302c0becb@haskell.org> References: <051.47ebb92305025f856dac567302c0becb@haskell.org> Message-ID: <066.9caf42aacb2f4dbd767b74b2e422118f@haskell.org> #13177: Give Data.Functor.* its lifted void and unit -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interesting idea. I do admit that I'm not a fan of having copies of every common `(* -> *)`-kinded datatype in `GHC.Generics`, but sadly, that's the way it is right now. I think it might be an interesting proposal idea to add non-`GHC.Generics` versions of `V1` and `U1` to the `Data.Functor.*` namespace in `base`. But of course, the hardest part is naming, as always. I'm not terribly found of the name `V0` for lifted unit, given its linear algebra connotation. As another point of reference, the `trivia` package on Hackage calls lifted void and unit `Zero` and `One`, respectively. So do you want to be the adventurous spirit that chooses a set of names to rally behind and argue for them on the libraries mailing list? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 18:03:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 18:03:46 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.d50e2473c98e82cbe23880a7b7122c79@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carette): The `DerivingStrategies` web page is actually easier to find (I referenced it when I first asked the question https://mail.haskell.org/pipermail /haskell-cafe/2016-October/125378.html). Yes, recapping the stock derivable instances along with the extras that GHC also implements would work for me. Perhaps in the prelude to 9.6 (i.e. before 9.6.1)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 18:13:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 18:13:40 -0000 Subject: [GHC] #13182: Rethinking dataToTag# Message-ID: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> #13182: Rethinking dataToTag# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | 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: -------------------------------------+------------------------------------- We currently use a primop `dataToTag#` that requires some careful handling because it can only be applied to something that has already been evaluated. We (now) mark it `can_fail` to prevent it from floating out, and then add a fix-up pass in CorePrep just in case things went wrong. Could we do something simpler? Suppose we had {{{#!hs -- The real primop, preferably not exported from *anywhere*, but at least documented as never to be used outside GHC. secretDataToTag# :: a -> Int# -- A wired-in safe version dataToTag# :: a -> Int# dataToTag# !a = secretDataToTag# a {-# NOINLINE dataToTag# #-} }}} Then `dataToTag#` could be inlined in CorePrep, just like `runRW#`. === Questions === How would this interact with float out? It should be perfectly safe to float out when its argument is known to be forced, but it seems likely we'll run into let/app invariant failures. What RULES do we (or should we) have for `dataToTag#`? How will this change affect them? My vague recollection is that we don't have any, but it would be pretty nice to apply something equivalent to case-of-known- constructor. Whenever `dataToTag#` is applied to a known constructor, we should be able to evaluate it. The earlier we do this the better it will inform simplification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 18:19:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 18:19:48 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.6ce330413e975e383833fb96d75953e2@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That sounds agreeable to me! Do you want to take a crack at fixing the users' guide? The relevant part of the codebase that you'd have to change is here: http://git.haskell.org/ghc.git/blob/9fd87ef8a16fbbce35205ae63d75d239bb575ccc:/docs/users_guide/glasgow_exts.rst#l3192 And if you want to preview what your changes look like, you can either build just the docs (see [https://ghc.haskell.org/trac/ghc/wiki/Building/Docs#UsersGuide these instructions]), or you can fork GHC on GitHub and view a rendered version of `docs/users_guide/glasgow_exts.rst` directly (for example, see [https://github.com/ghc/ghc/blob/master/docs/users_guide/glasgow_exts.rst this]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 18:20:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 18:20:32 -0000 Subject: [GHC] #13179: Levity-polymorphic data types In-Reply-To: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> References: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> Message-ID: <066.5325b5dad0eabec35758a86c4150adf5@haskell.org> #13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm afraid your definitions may not be what you think they are. In particular, the way you've written your GADT constructors forces `TYPE rep ~ Type`, so in effect they're not much different from `Product`, `Sum`, and `Compose` and they exist today in `base`. If you tried to write truly levity polymorphic definitions for, say, `Product`, it'll actually be rejected! {{{#!hs data Product :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where Pair :: forall rep k (f :: k -> TYPE rep) (g :: k -> TYPE rep) (a :: k). f a -> g a -> (Product f g) a }}} {{{ :9:85: error: • A levity-polymorphic type is not allowed here: Type: f a Kind: TYPE rep • In the definition of data constructor ‘Pair’ In the data type declaration for ‘Product’ :9:85: error: • A levity-polymorphic type is not allowed here: Type: g a Kind: TYPE rep • In the definition of data constructor ‘Pair’ In the data type declaration for ‘Product’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 19:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 19:05:35 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted void and unit In-Reply-To: <051.47ebb92305025f856dac567302c0becb@haskell.org> References: <051.47ebb92305025f856dac567302c0becb@haskell.org> Message-ID: <066.b66b52627b17c121af5825e72b2d8959@haskell.org> #13177: Give Data.Functor.* its lifted void and unit -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:3 RyanGlScott]: > I do admit that I'm not a fan of having copies of every common `(* -> *)`-kinded datatype in `GHC.Generics`, … Agreed but is merging them a realistic option? > As another point of reference, the `trivia` package on Hackage calls lifted void and unit `Zero` and `One`, respectively. I like those names. As long as the name is consistent I'm happy. I have heard `Void`, `Empty`, `Null`, `Vacuous`, `Finalize` / `Initialize`, `Terminal` / `Initial`, `Naught`. Even `DevNull` :-) > So do you want to be the adventurous spirit that chooses a set of names to rally behind and argue for them on the libraries mailing list? Ack! Sure, I don't like dealing with the mailing lists though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 19:13:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 19:13:36 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted void and unit In-Reply-To: <051.47ebb92305025f856dac567302c0becb@haskell.org> References: <051.47ebb92305025f856dac567302c0becb@haskell.org> Message-ID: <066.2d9b9d56d0b070df9f58c901e4ca22a1@haskell.org> #13177: Give Data.Functor.* its lifted void and unit -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 Iceland_jack]: > Agreed but is merging them a realistic option? In the short term, probably not. But it is on my radar after ekmett pitched the idea in https://ghc.haskell.org/trac/ghc/ticket/11650#comment:11. It's possible that we might want to merge the datatypes in `GHC.Generics` with their `Data.Functor.*` counterparts someday with clever uses of pattern synonyms. I dunno. > > As another point of reference, the `trivia` package on Hackage calls lifted void and unit `Zero` and `One`, respectively. > > I like those names. If you like the names `Zero` and `One`, great! I don't think it'd be wise for me to just plop datatypes into `base` without warning, or else folks who care about this stuff might come after me with pitchforks :) That's why I always advise folks to consult the libraries mailing list if they're in doubt. It can be tedious, I know, but it's the best solution we have to make sure that what goes into the core libraries doesn't create a rift with those who actually use it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 19:29:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 19:29:53 -0000 Subject: [GHC] #13161: Unexpected error about untouchable variable In-Reply-To: <046.71521d854360f3a0b03321165873dad9@haskell.org> References: <046.71521d854360f3a0b03321165873dad9@haskell.org> Message-ID: <061.e2f029b12ed275e34fa997cc7dc6d911@haskell.org> #13161: Unexpected error about untouchable variable -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: 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: | -------------------------------------+------------------------------------- Comment (by danilo2): Richard, thanks for the explanation. I'm closing the ticket right now, but after reading the docs I might re-open it with some further thoughts. Thank you once again! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 19:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 19:30:12 -0000 Subject: [GHC] #13161: Unexpected error about untouchable variable In-Reply-To: <046.71521d854360f3a0b03321165873dad9@haskell.org> References: <046.71521d854360f3a0b03321165873dad9@haskell.org> Message-ID: <061.6e31fbc6ff2ae9fb26bd6e08e05545fe@haskell.org> #13161: Unexpected error about untouchable variable -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 20:57:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 20:57:52 -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.faee2bafee2b11b7556f1ae408007315@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 dfeuer): Unfortunately, part of niteria's change was semantically invalid and needed to be reverted. I'm trying to understand a little more of what's going on around it that makes it a hot spot. niteria's observation that we almost always reach the `otherwise` suggests that perhaps we can find a quicker way to get there (rather than checking if each contains the other immediately, first find a way to discover or approximate that they certainly don't). But working out the asymptotic problems will surely be more important than that. Right now I'm struggling a bit to understand what `mkTick` is doing and how. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 21:02:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 21:02:30 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.cfe9e573c2467a6519a2ef749970c2f7@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carette): Yes, I'll give it a crack. Does this mean that I should 'own' this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 21:09:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 21:09:30 -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.cf4c293192d9002d042f7142c302acff@haskell.org> #13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D3016 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 21:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 21:30:03 -0000 Subject: [GHC] #13179: Levity-polymorphic data types In-Reply-To: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> References: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> Message-ID: <066.aa3c12a24a922743b421675ae7422127@haskell.org> #13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 RyanGlScott]: > I'm afraid your definitions may not be what you think they are. Yes. GHC will do levity polymorphism only upon request, and there is no request in your data constructor types. > If you tried to write truly levity polymorphic definitions for, say, `Product`, it'll actually be rejected! As well they should be. When creating data constructors, we need to know representations of their fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 21:49:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 21:49:45 -0000 Subject: [GHC] #12713: Bytes allocated statistic for T10858 differs between Windows and Linux In-Reply-To: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> References: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> Message-ID: <061.9f2e15d8585dcdcd8f806f15684c2f79@haskell.org> #12713: Bytes allocated statistic for T10858 differs between Windows and Linux ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.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 Ben Gamari ): In [changeset:"2aaafc8b9788e4a3447a10740479e0e7c0622cda/ghc" 2aaafc8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2aaafc8b9788e4a3447a10740479e0e7c0622cda" Bump Win32 version. Bump the version of `Win32` to `2.5.0.0` which is a major update and includes fixes for wrong alignments and wrong 64-bit types. Strangely enough this also seems to resolve #12713, where `T10858` was failing due to too-low allocations. The underlying type aliases have changed, so there is a potential for user programs not to compile anymore, but the types were incorrect. This also requires a bump in the `directory`, `Cabal`, and `process` submodules. Original author: Tamar Christina Test Plan: ./validate Reviewers: bgamari, RyanGlScott, austin Subscribers: hvr, RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2938 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 22:05:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 22:05:14 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.bbce6596987f834b0822f9081692aeda@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: | -------------------------------------+------------------------------------- Comment (by goldfire): Bad news and good news. Bad news first: my student who said she was keen on this has changed direction and will not be working on this in the near future. Good news: she's spending the semester learning more type theory, and I'm hoping to get her to tackle something like implication constraints or visible type application in patterns or something more type-y. Even better news: where there was originally one student, there are now three. So the future bodes well. In any case, I have no intention of myself or anyone in my immediate vicinity to work on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 22:09:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 22:09:41 -0000 Subject: [GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" In-Reply-To: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> References: <046.ec8db13b6efff688fc4aec1eff3b3d67@haskell.org> Message-ID: <061.90abfa549595d48b00fb168976d93ec4@haskell.org> #13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 carette]: > Yes, I'll give it a crack. Does this mean that I should 'own' this ticket? Sure, go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 22:45:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 22:45:59 -0000 Subject: [GHC] #12713: Bytes allocated statistic for T10858 differs between Windows and Linux In-Reply-To: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> References: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> Message-ID: <061.2b9f2f424a9dabb6ed2ba928736ddf3d@haskell.org> #12713: Bytes allocated statistic for T10858 differs between Windows and Linux ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Allocations on this test on Windows mysteriously rose to fall in the acceptance window with the above commit. Odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:03:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:03:33 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.b757cd8dd79093bce8d0b43125728f9d@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 dalaing): * cc: dalaing (added) Comment: If/when I start working on `pretty`, should I be tracking that work here, or in #10735? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:06:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:06:59 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.1500666d7795c8b4d3664f526f1b8aa5@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: dalaing Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:16:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:16:51 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.2a7392fd136a836d09529190144ac3a5@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: dalaing Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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): D3017 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => D3017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:22:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:22:23 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.abdebade65bef6aec28d2dd72eda6435@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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:65 goldfire]: > … something like implication constraints or visible type application in patterns … `<3`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:25:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:25:48 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.ed7871ab3718c610b2eb96c83e43ac82@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: dalaing Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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): Phab:D3017 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D3017 => Phab:D3017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:33:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:33:52 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.fb232e36538db192bc55d6d0dc16de1b@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: | -------------------------------------+------------------------------------- Comment (by bgamari): dalaing, I think #10735 is probably more appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:45:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:45:02 -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.23fc29fd9b6b36ac1e184c0e8f50d791@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 niteria): Comment https://ghc.haskell.org/trac/ghc/ticket/11095#comment:8 is based on invalid semantics, sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 24 23:48:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jan 2017 23:48:10 -0000 Subject: [GHC] #13179: Levity-polymorphic data types In-Reply-To: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> References: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> Message-ID: <066.69b2e38bd05c434503eed3abf9bb0ee1@haskell.org> #13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:2 RyanGlScott]: > I'm afraid your definitions may not be what you think they are. Fiddlesticks, I was worried something like this was happening. Replying to [comment:3 goldfire]: > As well they should be. When creating data constructors, we need to know representations of their fields. , could something like this work (possibly with UnliftedDataTypes) {{{#!hs Product :: forall rep₁ rep₂. (k -> TYPE rep₁) -> (k -> TYPE rep₂) -> (k -> TYPE (rep₁ <> rep₂)) }}} for some handwavey `Max` {{{#!hs Sum :: forall rep₁ rep₂. (k -> TYPE rep₁) -> (k -> TYPE rep₂) -> (k -> TYPE (Max rep₁ rep₂)) }}} More importantly, are there any '''actual''' cases in base/core amenable to levity polymorphism? If not I'll close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 01:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 01:42:39 -0000 Subject: [GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts Message-ID: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> #13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} module Bug where $([d| class Foo a instance Foo Int |]) }}} Used to pretty-print like this on GHC 8.0.2: {{{ Bug2.hs:(5,3)-(7,6): Splicing declarations [d| class Foo_a13B a_a13C instance Foo_a13B Int |] ======> class Foo_a3Jo a_a3Jp instance Foo_a3Jo Int }}} But on GHC HEAD, it prints a redundant instance context! {{{ Bug2.hs:(5,3)-(7,6): Splicing declarations [d| class Foo_a1eh a_a1ei instance Foo_a1eh Int |] ======> class Foo_a4ly a_a4lz instance () => Foo_a4ly Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 01:54:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 01:54:42 -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.8e0cecb164f0957c823b2da2c848d0fb@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 dfeuer): I don't know if this is useful, but it's essential that `v` is not exported. If you export `v`, compilation is suddenly fast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 01:57:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 01:57:09 -0000 Subject: [GHC] #13179: Levity-polymorphic data types In-Reply-To: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> References: <051.f99b990ad79810c6aa4bb47fa59a297b@haskell.org> Message-ID: <066.967b511fa167979dd25c297af2474eb9@haskell.org> #13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'd need more info about your `Product` and `Sum` (constructors, usage sites) to know if they are feasible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 04:06:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 04:06:13 -0000 Subject: [GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts In-Reply-To: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> References: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> Message-ID: <065.11d33f3e7bf3467c18dab8c4c32b0b93@haskell.org> #13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template Haskell | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: alanz (added) Comment: This was introduced in 499e43824bda967546ebf95ee33ec1f84a114a7c (Add HsSyn prettyprinter tests). Alan, do you know what might be causing this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 04:13:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 04:13:29 -0000 Subject: [GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts In-Reply-To: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> References: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> Message-ID: <065.8c2a31da77eba6ac959bc98a96fda00d@haskell.org> #13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template Haskell | 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 RyanGlScott): Ah, I see that 499e43824bda967546ebf95ee33ec1f84a114a7c introduced a function called `pprHsContextAlways` which, as the name suggests, //always// prints out the context for an `HsQualTy`, even if it's empty. Is the solution here not to use `pprHsContextAlways` when printing out Template Haskell-spliced code? Or perhaps we should avoid constructing an `HsQualTy` in `hsSyn/Convert` when [http://git.haskell.org/ghc.git/blob/65cc7620517abec9b3e0d9bfe644accd5f649fe5:/compiler/hsSyn/Convert.hs#l257 converting] a Template Haskell `InstanceD` into a `ClsInstDecl`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 04:16:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 04:16:14 -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.ca40b542beb6d06739e8a9a81668da16@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.1 => 8.0.1 Comment: I compiled GHC 8.0.1 with the `devel2` flavor and it still gave the same panic: {{{ $ ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Case ( Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/basicTypes/Literal.hs:224:75 in ghc:Literal -1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 04:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 04:47:26 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.613b58feb49ac54135e95ffc59547d34@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 04:51:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 04:51:34 -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.17e307d28b9dd1f4993170f8a77d17bc@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I did some cursory debugging of this tonight. Here are my findings 1. This bug was definitely introduced in 6746549772c5cc0ac66c0fce562f297f4d4b80a2. (Add kind equalities to GHC.) Not the most surprising turn of events, I know, but still nice to have confirmed. 2. The lines of code that actually produce this error are in [http://git.haskell.org/ghc.git/blob/65cc7620517abec9b3e0d9bfe644accd5f649fe5:/compiler/rename/RnTypes.hs#l1690 RnTypes]: {{{#!hs extract_tv :: TypeOrKind -> Located RdrName -> FreeKiTyVars -> RnM FreeKiTyVars extract_tv t_or_k ltv@(L _ tv) acc | isRdrTyVar tv = case acc of FKTV kvs k_set tvs t_set all | isTypeLevel t_or_k -> do { when (occ `elemOccSet` k_set) $ mixedVarsErr ltv ; return (FKTV kvs k_set (ltv : tvs) (t_set `extendOccSet` occ) (ltv : all)) } | otherwise -> do { when (occ `elemOccSet` t_set) $ mixedVarsErr ltv ; return (FKTV (ltv : kvs) (k_set `extendOccSet` occ) tvs t_set (ltv : all)) } | otherwise = return acc where occ = rdrNameOcc tv }}} where `mixedVarsErr ltv` actually throws the "used as both a kind and a type" error. I decided to do some `pprTrace` debugging in this neighborhood, and I discovered that when you run the program above, the error gets thrown in the `isTypeLevel t_or_k` case. Here's some values at the moment of the error: {{{ RGS typelevel kvs : [k_a1ly] k_set : [vESeYM :-> k] tvs : [] t_set : [] all : [k_a1ly] tv : k_a1lx rdrNameOcc tv (occ) : k }}} What does this mean? I don't yet—I'll need to do some more digging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 05:30:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 05:30:23 -0000 Subject: [GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts In-Reply-To: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> References: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> Message-ID: <065.686a4a2ba80c434a5ee25fa4c55b2268@haskell.org> #13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | 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:D3018 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3018 Comment: I think the second option is cleaner, so I went with that approach in Phab:D3018. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 07:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 07:34:51 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.5d62219a10ef1bb5be000292a0e2da0c@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: 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:D3109 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: Phab:D1205 => Phab:D1205, Phab:D3109 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 07:37:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 07:37:58 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.52362aa67a3de60cadcc57a38a07a63a@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: 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:D3109 -------------------------------------+------------------------------------- Comment (by dalaing): I'm not sticking my hand up to dive into the depths of this, but I made the change from `foldr1` to `foldl1` and run a validate in case that's what people want for the time being. Feel free to knock the patch on the head if folks want to go for a deeper / more involved approached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 09:00:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 09:00:00 -0000 Subject: [GHC] #13182: Rethinking dataToTag# In-Reply-To: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> References: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> Message-ID: <060.291a700d238b224bd56d5935b1ed1443@haskell.org> #13182: Rethinking dataToTag# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | 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 simonpj): > Then dataToTag# could be inlined in CorePrep, just like runRW#. I think that is precisely equivalent to what happens now, so yes it'd be ok. But then `CorePrep` would need to be able to eliminate the freshly- introduced case if it was redundant: {{{ case x of { DEFAULT -> dataToTag# x } }}} Now if we inline `dataToTag#` we'll get a second case that must be eliminated. The simplifier does this already. To me the status quo looks simpler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 10:33:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 10:33:43 -0000 Subject: [GHC] #13184: :show bindings broken under -fexternal-interpreter Message-ID: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> #13184: :show bindings broken under -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- This is straight from GHC HEAD: {{{ $ ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter GHCi, version 8.1.20170123: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/bnitka/.ghc/ghci.conf package flags have changed, resetting and loading new packages... Loaded GHCi configuration from /home/bnitka/.ghci Prelude> let a = 1 Prelude> :show bindings a :: Num p => p = *** Exception: ghc-stage2: this operation requires -fno-external- interpreter Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 11:13:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 11:13:02 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.0fe68f98ec86ba33f434276aef8547ea@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | 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 heisenbug): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 11:18:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 11:18:13 -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.bb0d3808049f14defd336f95ee320447@haskell.org> #13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 13:51:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 13:51:48 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.34013a60dc22fb9e2f0bf11a8832a344@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnislaih): * cc: mnislaih (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 16:07:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 16:07: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.ebf082efda1658602643e8e8de8c2b41@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I _think_ I know what's happening here. The kind equalities patch changed `FreeKiTyVars` from this: {{{#!hs type FreeKiTyVars = ([RdrName], [RdrName]) }}} to this: {{{#!hs data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] , _fktv_k_set :: OccSet -- for efficiency, -- only used internally , fktv_tys :: [Located RdrName] , _fktv_t_set :: OccSet , fktv_all :: [Located RdrName] } }}} Now `FreeKiTyVars` is using two `OccSets`. (One each for the kind and type variables extracted so far? That's what I'm guessing, since `Note [Kind and type-variable binders]` is out of date.) The problem is that two exact `RdrName`s reified from Template Haskell can have the same underlying `Unique` but with different `Name`s (see `Note [Local bindings with Exact Names]`). That is what is shown in comment:7 — two exact `RdrName`s (`k`) have the same `Unique` (`vESeYM`), but different `Name`s (`a1lx` and `a1ly`). But as far as fixing this goes, I am a bit clueless. I suppose we could add `NameSet`s to `FreeKiTyVars` as well that track only `Exact` `RdrName`s, and if `lookupLocalRdrEnv` finds a hit for an `RdrName`, we could use the corresponding `NameSet`. Otherwise, fall back to the `OccSet`. Thoughts, Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 18:08:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 18:08:21 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) Message-ID: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: build | Blocked By: relational-query with ghc 8.0.2 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, this seems a regression of ghc 8.0.2 since 8.0.1 was building it fine: https://launchpadlibrarian.net/303858976/buildlog_ubuntu-zesty-amd64 .haskell-relational-query_0.8.3.2-2build1_BUILDING.txt.gz as you can see in the build log: Preprocessing test suite 'sqls' for relational-query-0.8.3.2... [1 of 3] Compiling Model ( test/Model.hs, dist-ghc/build/sqls /sqls-tmp/Model.o ) [2 of 3] Compiling Lex ( test/Lex.hs, dist-ghc/build/sqls /sqls-tmp/Lex.o ) [3 of 3] Compiling Main ( test/sqlsEq.hs, dist-ghc/build/sqls /sqls-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone runReaderT To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 405365 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc- stamp' failed make: *** [build-ghc-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 thanks, Gianfranco -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 18:25:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 18:25:59 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.9277adaa4b24362b98348c81e1f59792@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded @@ -7,0 +7,1 @@ + {{{ @@ -29,0 +30,1 @@ + }}} New description: Hello, this seems a regression of ghc 8.0.2 since 8.0.1 was building it fine: https://launchpadlibrarian.net/303858976/buildlog_ubuntu-zesty-amd64 .haskell-relational-query_0.8.3.2-2build1_BUILDING.txt.gz as you can see in the build log: {{{ Preprocessing test suite 'sqls' for relational-query-0.8.3.2... [1 of 3] Compiling Model ( test/Model.hs, dist-ghc/build/sqls /sqls-tmp/Model.o ) [2 of 3] Compiling Lex ( test/Lex.hs, dist-ghc/build/sqls /sqls-tmp/Lex.o ) [3 of 3] Compiling Main ( test/sqlsEq.hs, dist-ghc/build/sqls /sqls-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone runReaderT To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 405365 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc- stamp' failed make: *** [build-ghc-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 }}} thanks, Gianfranco -- Comment: Please provide instructions how to reproduce this so we can investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 18:28:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 18:28:55 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.ae0916b0549f2606415cc85b50f1de4e@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): hello, it should be reproducible by just rebuilding haskell-renational- query with ghc 8.0.2 If you have a debian based system (or a ppa access) pbuilder-dist zesty create pbuilder-dist zesty login apt-get install ubuntu-dev-tools liburi-perl wget pull-debian-source haskell-relational-query cd haskell-* dpkg-buildpackage (install missing stuff) dpkg-buildpackage failure :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 18:29:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 18:29:18 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.0615621834e8d3fae24afb2d8696ea8d@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by LocutusOfBorg): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 19:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 19:57:44 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.0eae80377c84d8e300d12f3fcf05c6d6@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * component: Compiler (Linking) => Template Haskell * architecture: x86_64 (amd64) => Unknown/Multiple Comment: The linker didn't change between `8.0.1` and `8.0.2`. I think this is a general limitation of TH. At least the current implementation. The linker is correct in saying you have a duplicate symbol. One is coming from the code that `inline-c` generates, which ends up producing a symbol called `rgb` (probably from the macro `RGB` in `windows.h`). The second comes from the `Win32` package. The `8.0.2` linker should have explicitly pointed these out. The issue is that TH uses a version of `Win32` that has all the symbols in the same object file. So the link has no choice but to load it all, even if you don't use `rgb` because it's in the same object file. If instead TH would use the archive instead of the `whole-package-as-object-file` variant then it should work. I'll leave this open so someone who knows more about TH can comment on the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 20:27:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 20:27:07 -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.bdc213d8212ffd4e71efda46ab1d8432@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yuck yuck yuck. The problem is that this code assumes that two variables with the same `OccName` are the same. This will always be true in user- written code. But it's not true with `Exact` names. Ryan's suggestion to fix this makes some sense, but it's very heavy. I will propose something altogether radical: skip the check for `Exact` names. This check serves but one purpose: to allow people who want `-XPolyKinds` but are skittish about `-XTypeInType` to know that they have wandered into `-XTypeInType`-land. I foresee a future where `-XTypeInType` and `-XPolyKinds` become synonymous (not unlike how `-XRankNTypes` and `-XRank2Types` are synonymous) and this whole check can be dropped. Template Haskell already is somewhat anarchic about when it requires extensions. This choice would contribute to the anarchy, but in a very small way. And it's very easy to just skip the check! To be clear: the only people this hurts are people who want to avoid `-XTypeInType` while still using Template Haskell and who happen to use TH to generate some code that is accepted only with `-XTypeInType`. (And who like the letter `k`.) I argue that this set of people is small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 23:30:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 23:30:26 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.59161702e74b3aa79c669f9ee8f0882b@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What happened when you increased `simpl-tick-factor`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 25 23:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jan 2017 23:46:29 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.5d718afaa2767eafdb70c005ddb89787@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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:D3012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you give an exmaple of were this is helpful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 00:06:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 00:06:59 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.6be308906db5cfd0200b2941f8c7b4b4@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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:D3012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yes. Consider `runST` for ''lazy'' `ST`. We currently have {{{#!hs runST :: (forall s. ST s a) -> a runST st = case st of ST the_st -> let (r,_) = the_st (S# realWorld#) in r {-# NOINLINE runST #-} }}} If we want to switch to `runRW#` using today's `runRW#`, we need to do something like this: {{{#!hs runST (ST st) = case runRW# (\s -> case st (S# s) of (r, _s') -> (# s, r #)) of (# _, r #) -> r }}} That is, we need to pack up the result with a state token to satisfy the type of `runRW#`. Note that we'd use the token we got from `runRW#` because opening up the one `st` returned would force actions that may not be necessary. Then once we have the result from `runRW#`, we have to match on it again to remove the unneeded state token. With the more general type, we can write this as {{{#!hs runST (ST st) = runRW# (\s -> case st (S# s) of (r, _) -> r) }}} Much simpler, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 00:23:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 00:23:04 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.10c891f16cca9a1376838fcead6d7079@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"1a3f1eebf81952accb6340252816211c7d391300/ghc" 1a3f1ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a3f1eebf81952accb6340252816211c7d391300" COMPLETE pragmas for enhanced pattern exhaustiveness checking This patch adds a new pragma so that users can specify `COMPLETE` sets of `ConLike`s in order to sate the pattern match checker. A function which matches on all the patterns in a complete grouping will not cause the exhaustiveness checker to emit warnings. ``` pattern P :: () pattern P = () {-# COMPLETE P #-} foo P = () ``` This example would previously have caused the checker to warn that all cases were not matched even though matching on `P` is sufficient to make `foo` covering. With the addition of the pragma, the compiler will recognise that matching on `P` alone is enough and not emit any warnings. Reviewers: goldfire, gkaracha, alanz, austin, bgamari Reviewed By: alanz Subscribers: lelf, nomeata, gkaracha, thomie Differential Revision: https://phabricator.haskell.org/D2669 GHC Trac Issues: #8779 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 00:23:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 00:23:04 -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.d18ecbbc2d2326c646451670f4f43d07@haskell.org> #13098: Template Haskell support for Pattern Synonym's Complete Pragma -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"95dc6dc070deac733d4a4a63a93e606a2e772a67/ghc" 95dc6dc0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="95dc6dc070deac733d4a4a63a93e606a2e772a67" Template Haskell support for COMPLETE pragmas Reviewers: RyanGlScott, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2997 GHC Trac Issues: #13098 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 00:23:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 00:23:11 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.9e61d75437e73b626c38dec3edd89236@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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:D3012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I see. Yes, ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 00:28:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 00:28:12 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.fd1bfe96451e387594daef3ecd08c7e7@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: | -------------------------------------+------------------------------------- Changes (by zyla): * cc: zyla (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 00:28:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 00:28:14 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.119975209820ad275c4b30fd2b8341f3@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: 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:D3109 -------------------------------------+------------------------------------- Comment (by ekmett): Sounds good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 02:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 02:31:54 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.a794a67e18a9baafd16e427f23ab9c8f@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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:D3012 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"c344005b2344800bee9fee1c5ca97867691b9c70/ghc" c344005b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c344005b2344800bee9fee1c5ca97867691b9c70" Generalize the type of runRW# * Generalize the type of `runRW#` to allow arbitrary return types. * Use `runRW#` to implement `Control.Monad.ST.Lazy.runST` (this provides evidence that it actually works properly with the generalized type). * Adjust the type signature in the definition of `oneShot` to match the one it is given in `MkId`. Reviewers: simonmar, austin, bgamari, hvr Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3012 GHC Trac Issues: #13178 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 02:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 02:37:00 -0000 Subject: [GHC] #13178: Generalize type of runRW# In-Reply-To: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> References: <045.ab067a9c5d664d802570323252f36bc2@haskell.org> Message-ID: <060.7f92d9ddb5eff5190890476f541f533f@haskell.org> #13178: Generalize type of runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | 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:D3012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 03:30:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 03:30:35 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.2d17ccb31e88509b3e66c101115a1336@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 (Parser) | 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 dalaing): It looks like these are the various warnings that can be generated by the parser: If `Opt_WarnTabs` is set: * the tab warnings are collected and summarised If `Opt_WarnUnrecognisedPragmas` is set: * "Unrecognised pragma" If `Opt_WarnAlternativeLayoutRuleTransitional` is set: * "`where' clause at the same depth as implicit layout block" * "`|' at the same depth as implicit layout block" I think it's probably reasonable to print all of the warnings generated during parsing in the event of an unsuccessful parse. The other option would be to print the tab warning and suppress the others. I'm not sure we have enough structure in the warnings at the moment to do anything more fine grained unless we filtered them based on their warning strings. Adding an ADT for the warnings would help with that, and could be a positive step for later, but it's not something we need right now if folks agree that we always want to print all of the warnings on an unsuccessful parse. I'm going to start working on a change that prints warnings on unsuccessful parses (except perhaps for HeaderInfo.getImports, which has a note in it about not logging warning) and see how that goes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 03:32:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 03:32:59 -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.4472714fb5ad172ef6729b1dc38000ff@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3022 Comment: Richard, that proposal sounds even better, so I went with that approach in Phab:D3022. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 03:53:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 03:53:54 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.359028929ebef99e71a70718cb36e1d9@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 (Parser) | 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 dfeuer): That sounds pretty reasonable to me. Just make sure you limit the output size however (if at all) it's limited elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 05:29:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 05:29:02 -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.20a8c54b9977f54f4d137df4c85588bc@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 dfeuer): It appears that a big problem here is in `wrapTicks` in `coreSyn/CorePrep.hs`. In particular, tracing its `go` function like this {{{#!hs go (FloatTick t) (fs, e) = ASSERT(tickishPlace t == PlaceNonLam) pprTrace "mapOL called with" (text "t = " <+> ppr t $$ text "fs = " <+> ppr fs) (mapOL (wrap t) fs, mkTick t e) go other (fs, e) = (other `consOL` fs, e) }}} produces a huge amount of output, showing that the `fs` get deeper and deeper, layering tick on tick on tick at least quadratically. See [http://lpaste.net/2018094287874424832 this paste]. Every step in the fold calls `mapOL (wrap t)` on the (growing) accumulator list. I wonder if it might be possible to find a way to combine these ticks, or drop some of them, instead of layering them arbitrarily deeply. I don't know how many we need. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 06:55:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 06:55:14 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.8506fcfada7c24371dc984a18eb3be30@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 (Parser) | 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 dalaing): It looks like getting this to work while keeping the ability to run the parser with a pure function might involve modifying the `PFailed` constructor from the `ParseResult` data type. It's not the end of the world, but I figure it's worth mentioning in case folks have objections. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 07:11:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 07:11:15 -0000 Subject: [GHC] #13186: Change EvNum to EvNum :: Natural -> EvLit Message-ID: <045.e9472df3c9da56f1cd7efedf1a6ea89f@haskell.org> #13186: Change EvNum to EvNum :: Natural -> EvLit -------------------------------------+------------------------------------- Reporter: phadej | 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: #8306 #8412 | #13181 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we carry `Nat` kind as an Integer internally. Just changing the type of EvNum (and related isomorphic types like `HsTyLit` etc) does pretty far. The core problem is that we should be able to output Natural literals into Core. Also this would need change to parser, to accept only Naturals in types. Currently negative literals are caught in the renamer (due the fact that template-haskell might inject negative integers as well). This will propagate to template-haskell, changing TyLit there as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 08:50:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 08:50:06 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.95e9ed7222cf4cddfe5ed7442c49ec36@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by magesh.b): * cc: magesh.b (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 09:48:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 09:48:36 -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.6db64c5eb06df3d328843fd6dbd456ff@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 mpickering): This seems very invasive but for what? The situation where the internal representation is an `Integer` but the representation exposed is a `Natural` seems much easier to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 09:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 09:57:44 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.93a47963d62dddc723f0c74d0008709c@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 (Parser) | 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 mpickering): Right, this is the worry I was talking to you about on IRC. You could instead make the return type of the parser monad `(DynFlags -> [Errs], ParseResult a)` if that is clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 12:06:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 12:06:23 -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.0662805121f3d0c673023f76930d87ac@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): On the other hand: > This smells funny. Why is there so much Integer here? Why is a conversion from Integer to Natural being put in such deep code? I'm clearly missing something! https://phabricator.haskell.org/D3024 AFAICS, it's totally possible to thread Natural thru the pipeline, we do very little calculations with type level nats (in a single module), everywhere else the value is just passed forward. Like in https://github.com/ghc/ghc/blob/ff9355e48d0cb04b3adf26e27e12e128f79618f4/compiler/typecheck/TcInteract.hs#L2106 And then we could use `minusNaturalMaybe` https://github.com/ghc/ghc/blob/ff9355e48d0cb04b3adf26e27e12e128f79618f4/compiler/typecheck/TcTypeNats.hs#L691 here, i.e. unify `Natural` and `KnownNat` handling by ''using same functions''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 13:20:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 13:20:24 -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.0e238c25bbc6a28e98b7934c6eca0027@haskell.org> #13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3016 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"0d1cb1574dd58d1026cac812e2098135823fa419/ghc" 0d1cb157/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d1cb1574dd58d1026cac812e2098135823fa419" Make type import/export API Annotation friendly Summary: At the moment an export of the form type C(..) is parsed by the rule ``` | 'type' oqtycon {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2))) [mj AnnType $1,mj AnnVal $2] } ``` This means that the origiinal oqtycon loses its location which is then retained in the AnnVal annotation. The problem is if the oqtycon has its own annotations, these get lost. e.g. in type (?)(..) the parens annotations for (?) get lost. This patch adds a wrapper around the name in the IE type to (a) provide a distinct location for the adornment annotation and (b) identify the specific adornment, for use in the pretty printer rather than occName magic. Updates haddock submodule Test Plan: ./validate Reviewers: mpickering, dfeuer, bgamari, austin Reviewed By: dfeuer Subscribers: dfeuer, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3016 GHC Trac Issues: #13163 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 14:12:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 14:12:21 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.cf9333bb18a0b3e79cbf41c8b067307a@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): I think it would be a good approach to keep the current delay, but to insert some kind of conditional around actually running the full GC. This condition could take into account e.g.: - The time since the last (actually-performed) idle GC. This would reset if a non-idle full GC is performed. - The number of bytes collected by the last idle GC, perhaps in relation to the residency. (If you collect less than 10% of heap as garbage, it is probably not worth to run the GC too often). - The number of bytes allocated since the last full GC (idle or not). I don't know if these statistics are available, but at least the first should be easy to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 14:27:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 14:27:50 -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.e7eca4a4bee77ddf101c5ab02f64beda@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 EyalLotem): Much smaller example that reproduces the issue: {{{ data A a = A (B a) (B a) deriving (Functor) data B a = B (A a) deriving (Functor) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 15:48:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 15:48:20 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.7a7376d9eb52297cfbaa138df1dfd55c@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The main purpose of the idle GC is not really to collect garbage, it's for deadlock detection. The program may have deadlocked even if it has only allocated a tiny amount since the previous GC, and we have no way of telling that. On the other hand, if you want the idle GC for collecting garbage, and you don't mind about not having prompt deadlock detection, then yes having those heuristics would be a good idea. I'm just not sure how often this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 15:51:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 15:51:10 -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.c050cacbe88793f8b811ca8db2d159a0@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 scpmw): Right, the source note gets floated outside of the `(:)` application, at which point the inner-most `()` is covered by source notes of all `()` in the list. Thus we get a quadratic growth of source notes, and redundancy checks blow this up to `O(n^3)`. Ouch. Ironically, this would likely not happen without the syntactic sugar, as then a source note would span the whole `(a:b)` expression (instead of just `b`), which would get eliminated by the mentioned "contains" check. This is what normally gives this stability: Once a tick gets flown up, it immediately hits a tick that covers a greater span, causing it to get eliminated. So maybe changing desugaring could actually take care of this. We could also attempt to merge ticks automatically. This would make them slightly less useful, but is clearly better than blowing up the compiler. On the other hand, not sure what the criterion for merging should look like. If we go by the span alone, we run into the tricky question of how far two spans can be apart until we must assume that merging them would stop making sense. Unfortunately, I doubt it would be hard to make up examples to make any given threshold look bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 16:13:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 16:13:27 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.6bcdb9ac82ee4fbbd404e2951853fd90@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): I just noticed that this means that you do not get deadlock detection if you forkIO (forever (threadDelay 100000)). That's interesting. You are right, I was focused on GC performance instead of deadlock detection because the latter was not even mentioned when i chatted with rwbarton. Maybe he can comment on this. Even for deadlock detection it makes sense to delay things based on the cost of the full GCs. (I'd rather have to wait 15secs to get the deadlock detected when I manage to create deadlocks than constantly be wasting CPU time - but if full GCs are cheap, I would not mind quicker detection.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 17:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 17:06:11 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.ab15ece7dfb3b496cbd73bfc6b4f1c26@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: | -------------------------------------+------------------------------------- Comment (by diatchki): I am not sure I understand the issue here, could you provide an example using the new notation for incoherent and overlapping instances (i.e., where each instance is annotated individually, rather than having the global flag). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 17:48:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 17:48:42 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.08bca4847d83faa5d2ef2b748538c435@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: dalaing Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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): Phab:D3017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"3eebd1f5fd56689baa63fcc63b7f4bde0ae70d0b/ghc" 3eebd1f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3eebd1f5fd56689baa63fcc63b7f4bde0ae70d0b" Generalizes the type of asProxyTypeOf (#12805) Test Plan: validate Reviewers: austin, hvr, bgamari, RyanGlScott, simonpj Reviewed By: RyanGlScott, simonpj Subscribers: simonpj, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D3017 GHC Trac Issues: #12805 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 17:48:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 17:48:42 -0000 Subject: [GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts In-Reply-To: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> References: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> Message-ID: <065.93b4eff2b2309528332398d7d21473f0@haskell.org> #13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | 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:D3018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ad3d2dfa19a1ed788c682e8b0c7c6e66e63d3f79/ghc" ad3d2dfa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ad3d2dfa19a1ed788c682e8b0c7c6e66e63d3f79" Don't unnecessarily qualify TH-converted instances with empty contexts Summary: The addition of rigorous pretty-printer tests (499e43824bda967546ebf95ee33ec1f84a114a7c) had the unfortunate side-effect of revealing a bug in `hsSyn/Convert.hs` wherein instances are _always_ qualified with an instance context, even if the context is empty. This led to instances like this: ``` instance Foo Int ``` being pretty-printed like this! ``` instance () => Foo Int ``` We can prevent this by checking if the context is empty before adding an HsQualTy to the type. Also does some refactoring around HsForAllTys in `Convert` while I was in town. Fixes #13183. Test Plan: ./validate Reviewers: goldfire, bgamari, austin, alanz Reviewed By: alanz Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D3018 GHC Trac Issues: #13183 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 17:51:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 17:51:21 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.4a9bb74add06286e103949e1f73cf260@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: dalaing Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3017 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 17:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 17:53:42 -0000 Subject: [GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts In-Reply-To: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> References: <050.18ab8f03b9a7261253fbc18797c705bb@haskell.org> Message-ID: <065.6c5cf2b8bc136999c6e8d77f3d47556b@haskell.org> #13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3018 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:04:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:04:46 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.1e1cfcc84cdd123a9b2bcd30e222df39@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: 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): FWIW I've never cared about deadlock detection, and it sounds unreliable in view of lspitzner's most recent comment. I do care that interactive programs I'm not actively using don't consume 12% of my CPU. Doing a GC when the user isn't interacting with the program sounds like a good idea to hide latency. Judging from the detailed GC statistics lspitzner's program isn't totally idle; it must be doing a little bit of work every second, repeatedly triggering a new idle GC. But one would expect it to be cheap to do a little bit of work every second. The heap could be a lot bigger than 50 MB... The user's guide suggests enabling the idle GC for interactive programs, but when there is a little work to do every second it seems basically unusable. And the effects of the idle GC would be lost completely by doing work every 0.2 seconds, which is strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:12:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:12:16 -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.722bf748ca9ca669c67556ad53b87f57@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): I think I'm running into the same bug. A super minimal example is: {{{ go = case [] of (a:b) -> a {b = a} }}} Do we think this is the same bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:16:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:16:56 -0000 Subject: [GHC] #9432: IncoherentInstances are too restricted In-Reply-To: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> References: <046.664086b26b665cb6fc96ee44782f4d6f@haskell.org> Message-ID: <061.9ba13a9b523352fe9acf10d097c7cfde@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: | -------------------------------------+------------------------------------- Comment (by rwbarton): These two issues seem unrelated (the second one has something to do with functional dependencies) and should probably be in two separate tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:30:03 -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.84b51a0cb6ab202d7874b489275e90c7@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think it very well might be the same bug, considering the form of the panic is identical to how niteria originally reported it: {{{ $ ghci -fdefer-type-errors Bug.hsGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:3:16: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: (_ : _) -> ... Bug.hs:3:25: warning: [-Wdeferred-out-of-scope-variables] Variable not in scope: a :: A Bug.hs:3:25: warning: [-Woverlapping-patterns] Pattern match is redundant In a record-update construct:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): unused }}} Also reproducible on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:49:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:49:14 -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.bb39b9720a8217f29371748f26113145@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:49:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:49:20 -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.eeb7614e75816e36753c257f99bf9cb1@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I will get to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 18:53:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 18:53:07 -0000 Subject: [GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char Message-ID: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> #13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this when debugging an issue in `th-desugar`. If you have this file: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where type Const a b = b test36_expand = $([| let f :: Const Int (,) Bool Char -> Char f = snd in f |]) }}} And compile it on GHC HEAD with `-ddump-tc-trace` enabled, even if you redirect the output of `-ddump-tc-trace` to a file with `-ddump-to-file`, GHC will still print what appears to be debugging messages! {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs -ddump-to-file -fforce- recomp -ddump-tc-trace [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) isPredTy Const Int (,) Bool Char }}} The source of that `isPredTy` message is in `Type` ([http://git.haskell.org/ghc.git/blob/3eebd1f5fd56689baa63fcc63b7f4bde0ae70d0b:/compiler/types/Type.hs#l1523 here]): {{{#!hs go_k :: Kind -> [KindOrType] -> Bool -- True <=> ('k' applied to 'kts') = Constraint go_k k [] = isConstraintKind k go_k k (arg:args) = case piResultTy_maybe k arg of Just k' -> go_k k' args Nothing -> pprTrace "isPredTy" (ppr ty) False -- This last case should not happen; but it does if we -- we call isPredTy during kind checking, especially if -- there is actually a kind error. Example that showed -- this up: polykinds/T11399 }}} Several things stand out here: 1. Should we be using `pprTrace` this way? 2. Given that the comment says that "This last case should not happen", is this program indicative of a bug? Or perhaps this code really can be legitimately reached, and the comment should be updated to reflect this? FWIW, `polykinds/T11399` exhibits the same issue: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug2.hs -ddump-to-file -fforce- recomp -ddump-tc-trace [1 of 1] Compiling T11399 ( Bug2.hs, Bug2.o ) isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * Bug2.hs:10:32: error: • Couldn't match kind ‘*’ with ‘GHC.Types.RuntimeRep’ When matching kinds a :: * -> * TYPE :: GHC.Types.RuntimeRep -> * Expected kind ‘* -> *’, but ‘UhOh a’ has kind ‘a * -> *’ • In the first argument of ‘Functor’, namely ‘(UhOh a)’ In the instance declaration for ‘Functor (UhOh a)’ | 10 | instance Functor a => Functor (UhOh a) where | ^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 19:04:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 19:04:46 -0000 Subject: [GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char In-Reply-To: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> References: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> Message-ID: <065.e6c17565548524cf566dde372a5217be@haskell.org> #13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -6,1 +6,0 @@ - {-# LANGUAGE TemplateHaskell #-} @@ -10,3 +9,3 @@ - test36_expand = $([| let f :: Const Int (,) Bool Char -> Char - f = snd in - f |]) + + f :: Const Int (,) Bool Char -> Char + f = snd New description: I noticed this when debugging an issue in `th-desugar`. If you have this file: {{{#!hs {-# LANGUAGE PolyKinds #-} module Bug where type Const a b = b f :: Const Int (,) Bool Char -> Char f = snd }}} And compile it on GHC HEAD with `-ddump-tc-trace` enabled, even if you redirect the output of `-ddump-tc-trace` to a file with `-ddump-to-file`, GHC will still print what appears to be debugging messages! {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs -ddump-to-file -fforce- recomp -ddump-tc-trace [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) isPredTy Const Int (,) Bool Char }}} The source of that `isPredTy` message is in `Type` ([http://git.haskell.org/ghc.git/blob/3eebd1f5fd56689baa63fcc63b7f4bde0ae70d0b:/compiler/types/Type.hs#l1523 here]): {{{#!hs go_k :: Kind -> [KindOrType] -> Bool -- True <=> ('k' applied to 'kts') = Constraint go_k k [] = isConstraintKind k go_k k (arg:args) = case piResultTy_maybe k arg of Just k' -> go_k k' args Nothing -> pprTrace "isPredTy" (ppr ty) False -- This last case should not happen; but it does if we -- we call isPredTy during kind checking, especially if -- there is actually a kind error. Example that showed -- this up: polykinds/T11399 }}} Several things stand out here: 1. Should we be using `pprTrace` this way? 2. Given that the comment says that "This last case should not happen", is this program indicative of a bug? Or perhaps this code really can be legitimately reached, and the comment should be updated to reflect this? FWIW, `polykinds/T11399` exhibits the same issue: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug2.hs -ddump-to-file -fforce- recomp -ddump-tc-trace [1 of 1] Compiling T11399 ( Bug2.hs, Bug2.o ) isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * Bug2.hs:10:32: error: • Couldn't match kind ‘*’ with ‘GHC.Types.RuntimeRep’ When matching kinds a :: * -> * TYPE :: GHC.Types.RuntimeRep -> * Expected kind ‘* -> *’, but ‘UhOh a’ has kind ‘a * -> *’ • In the first argument of ‘Functor’, namely ‘(UhOh a)’ In the instance declaration for ‘Functor (UhOh a)’ | 10 | instance Functor a => Functor (UhOh a) where | ^^^^^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 20:12:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 20:12:18 -0000 Subject: [GHC] #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios Message-ID: <050.1e5d4c0f2a23fff6b57f4a536f55fb7d@haskell.org> #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a really bizarre one. If you have the following program: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Main where class LL f where go :: f a -> () instance LL [] where go _ = () pattern GoLL :: LL f => f a pattern GoLL <- (go -> ()) {-# COMPLETE GoLL :: [] #-} goLLEx :: [a] -> Int goLLEx GoLL = 5 main :: IO () main = return () }}} And you compile it with GHC HEAD in just the right way, GHC hangs forever! {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -no-link Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs # Hangs forever here }}} That `-no-link` part is crucial, since if you compile it straight from a source file, it works. Also worth noting: * I can reproduce this in GHC HEAD, but not in GHC 8.0.2. * The `COMPLETE` pragma is critical for triggering this bug. If you comment it out, then the issue disappears. Note that `cabal-install` installs executables using this `-no-link` strategy, so this bug effectively prevents me from using `cabal-install` with code that involves `COMPLETE` pragmas. Marking as high priority. I have //no// idea where to start looking for this one. Matthew, do you have any idea what might be happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 20:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 20:35:45 -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.e7f6cb38e95f874ad47d61d8e68e28d4@haskell.org> #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 20:37:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 20:37:38 -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.aa32a1dfdc0982cc4b2ffa1c4aba9be8@haskell.org> #13132: Compilation fails with a panic: get_op runContT -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: adamgundry Type: bug | Status: new 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 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2985 Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Yes, will do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 20:59:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 20:59:46 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.35b68c32a3b70bbb0f8e6acb6995729c@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): I've just ran into this bug, did you ever find a work-around? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 21:22:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 21:22:29 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.401db0a7a976ed6302bcdc44b15afeb8@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11525 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * related: => #11525 Comment: https://ghc.haskell.org/trac/ghc/ticket/11525 describes what's going on -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 22:58:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 22:58:12 -0000 Subject: [GHC] #13189: Implement same specification as GHC spec file for mingw32 Message-ID: <044.0d7b956789dcbf134cbfab9b7fb7505a@haskell.org> #13189: Implement same specification as GHC spec file for mingw32 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature | Status: new request | 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: #13093 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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`. Or specifying what `-mwindows` links in, that when `-lstdc++` is used what else to link in. Which base DLLs GCC will always link with when building an exe. And how to link `libgcc`, either static or dynamically. Currently we only support static linking of `libgcc` (which maybe we should change? or at least make user changeable). The current partial implementation works by adding hooks into the RTS. A better implementation is adding it all outside the RTS in the `DriverPipeline` tied directly to the commandline options. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 23:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 23:02:44 -0000 Subject: [GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal In-Reply-To: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> References: <050.56bf3974786c8b0939d295d2d066b6ab@haskell.org> Message-ID: <065.406d4926793bb4e3f53cb7c75d8cfa1f@haskell.org> #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- 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: T13082_good, | T13082_fail Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2941 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 23:04:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 23:04:44 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.57bc135b84188ed49518b32bf3e07e35@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: rwbarton (added) Comment: @rwbarton I believe you're the TH guy right? Any thoughts here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 23:08:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 23:08:28 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON Message-ID: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature | Status: new request | 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): Phab:D3010 | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the `-ddump-json` flag which is implemented by Phab:D3010. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 23:37:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 23:37:14 -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.50b7c119812d10381897e6faa922d927@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: Er, should the title of this be "Implement same specification as //GCC// spec file for mingw32"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 26 23:44:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jan 2017 23:44:46 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.ce8fc5c4965fdf9d481f83d452d9fcf1@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2998 Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"06b9561a2f10de68cc14b68a9bfa7617c0019bd9/ghc" 06b9561/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="06b9561a2f10de68cc14b68a9bfa7617c0019bd9" Fix the right-shift operation for negative big integers (fixes #12136) In `x shiftR y`, any of the following conditions cause an abort: - `x` is a negative big integer - The size of `x` and `y` is a multiple of `GMP_NUMB_BITS` - The bit of the absolute value of `x` is filled with `1` For example: Assuming `GMP_NUMB_BITS = 2`, the processing of `-15 shiftR 2` is as follows: 1. -15 = -1111 (twos complement: 10001) 2. right shift 2 (as a positive number) -> 0011 3. Due to the shift larger than GMP_NUMB_BITS, the size of the destination is decreasing (2bit) -> 11 4. Add 1, and get carry: (1) 00 5. abort I fixed it that the destination size does not decrease in such a case. Test Plan: I tested the specific case being reported. Reviewers: goldfire, austin, hvr, bgamari, rwbarton Reviewed By: bgamari, rwbarton Subscribers: mpickering, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2998 GHC Trac Issues: #12136 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 00:36:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 00:36:12 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.dfe5f251939f77bdcf43bde186d11e37@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2998 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 Fri Jan 27 01:06:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 01:06:12 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.5b248b4c6a96a5d976c72a8168f8ab8f@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The original issue turns out to be simply due to the fact that `inline-c` depends on `Win32` (via `directory`), and your program's cabal file states a dependency on your local version `Win32a`. `Win32` defines functions like `rgb` as wrappers around Windows API macros and your clone `Win32a` also defines functions with the same names. So you do have duplicate definitions for symbols. The issue doesn't have anything to do with `inline-c` besides the fact that it is causing the real `Win32` to be linked in. The issue is that, unlike symbols that come from Haskell functions, we don't mangle the symbols defined in C source files with the package identifier. I think there is a ticket about changing this, but for now it's a known limitation that you have to ensure that symbol names in C files you link in globally unique. Using the symbol name `rgb` in `Win32` is really not very good, as it is fairly likely to collide with someone else's symbol, and we should change that. In the `unix` package, we use symbol names like `__hsunix_ptsname`. However using a more GHC-specific symbol name would not help here, since you copied the `Win32` source into your own package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 01:09:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 01:09:09 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.afc771fdaae7fd097674af1428340887@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Also, what Phyx- says about TH loading the `.a` file instead of the `.o` file is probably true, since you don't actually use the object file that defines `rgb`. I guess it's possible that without TH your program would actually link successfully, for the same reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 01:21:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 01:21:29 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.0666b2cbad3dcd602f09cc39ff023de2@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): In the second reproducer, `child1`'s module `Lib` calls `rgb`, which is supposed to be defined by `child1`'s `HsGDI.c`. But the library `child1` does not have `c-sources: src/HsGDI.c`, only the (irrelevant) `child1-exe` does. It happens that `ghc-bug-maybe-exe` links indirectly against `Win32` (via `inline-c`), which coincidentally would provide a symbol `rgb`, but because there is no dependency of `child1` on `Win32`, it happened that `Win32` was given before `child1` on the linker command line and so the linker didn't know that there would be a reference to `rgb` when it processed `Win32`. The right thing to do of course is to specify `c-sources: src/HsGDI.c` in the `child1` ''library'' section; then you might get a duplicate symbol error again, because you chose the same name as `Win32` did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 01:21:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 01:21:55 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.11db0b71f08cb2ae1c44adb5d8af8847@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 01:24:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 01:24:41 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.26861ad7126744ac28ad6e14cf664b34@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): By the way, if ghc-mod doesn't build with ghc-8.0.2, please open a new ticket! Linkers are remarkably complicated beasts and every linker error is a unique snowflake. Having the two issues in the original report and in comment:3 on this ticket was already a little bit confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 02:23:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 02:23:48 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.7768a86c551f6f6e47595dbdb2fed58f@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeiea): ghc-mod problem turns out to be my fault that I was using haskell.org ghc distribution rather than github commercialhaskell/ghc release distribution. I submitted `rgb` symbol ticket by shallow thought caused from last phrase 'reportabug'. I thought ghc can ensure successful build despite this situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 02:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 02:37:41 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.a5b5e8fb1c50d4e86eea4b69e9011f38@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): BTW rwbarton, is #9351 the globally unique symbol names ticket you alluded to in comment:14? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 02:38:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 02:38:15 -0000 Subject: [GHC] #9351: add ability to version symbols .c for packages with C code In-Reply-To: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> References: <045.80bb3346a6b02dbb6a22b16b99e4840e@haskell.org> Message-ID: <060.a91437486dba6dfddce7903dd8feacfd@haskell.org> #9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 03:00:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 03:00:38 -0000 Subject: [GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char In-Reply-To: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> References: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> Message-ID: <065.c1107db63a77c73610d62eb733ae00ec@haskell.org> #13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, this use of `pprTrace` is poor. It should be changed to `WARNING`. I don't think it indicates a bug, though. The problem is that `Const` is over-saturated, in that it looks like it should take only two arguments but is given four. In this case, though, the over-saturation is just fine, as `Const` is polymorphic in its return kind, specialized to an arrow kind. It's conceivable that `isPredTy` will get it wrong, in this over-saturated case. But I don't see how to do better without zonking, etc., and so I vote to punt. It's only about pretty-printing anyway. If someone complains, we can re-examine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 03:02:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 03:02:05 -0000 Subject: [GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol In-Reply-To: <044.47110be31f0548a4f623e31c109dd321@haskell.org> References: <044.47110be31f0548a4f623e31c109dd321@haskell.org> Message-ID: <059.9e642789ec41eb113e5c17bad270ff6a@haskell.org> #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11223 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yep that's the one I was thinking of, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 03:09:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 03:09:42 -0000 Subject: [GHC] #13191: Make liftA2 a method of Applicative Message-ID: <045.6e3d12c3796dddf03258e755974fce1f@haskell.org> #13191: Make liftA2 a method of Applicative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.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): Phab:D3031 | Wiki Page: -------------------------------------+------------------------------------- Some functors support implementations of `liftA2` that are considerably faster than the usual definition. Furthermore, some people see `liftA2` as more intuitive and fundamental to the idea of `Applicative` than `<*>` is. This has been discussed on the libraries list in https://mail.haskell.org/pipermail/libraries/2017-January/027579.html and (as an official proposal) in https://mail.haskell.org/pipermail/libraries/2017-January/027612.html. All who expressed an opinion favored the proposal. One (David Menendez) specified that his support was weak. The others (Conal Elliot, Kris Nuttycombe, Wren Romano, Bardur Arantsson, and Mario Blažević) either supported the proposal strongly or merely indicated they were "+1". Conal Elliot wrote: [[BR]] [[BR]] > +1. > > I also sometimes define a specialized `liftA2` and then use it to define > `(<*>)`, which then gets used to define the real `liftA2`. > > I think of `liftA2` as playing a role similar to `foldMap` and `traverse`, while > `(<*>)` corresponds to `fold` and `sequenceA`. The first three self- compose > nicely: `liftA2.liftA2.liftA2`, `foldMap.foldMap.foldMap`, and > `traverse.traverse.traverse`. With functor composition, it's so much nicer to > write `liftA2.liftA2` (in the style of `Functor`, `Foldable`, and `Traversable`) > rather than `liftA2 (<*>)`. [[BR]] Wren Romano wrote [[BR]] [[BR]] > I'm also all for adding liftA2 to the class and have noticed this > inefficiency/asymmetry when working on the class hierarchies for other > languages [[BR]] Kris NuttyCombe wrote [[BR]] [[BR]] > I'm in favor of this change. From my perspecive, liftA2 is actually the > fundamental Applicative operation, an <*> is merely a convenient > isomorphism. When I'm teaching, showing the symmetry between the following > always seems to help students: > > fmap :: (a -> b) -> f a -> f b > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > flip (>>=) :: (a -> f b) -> f a -> f b > > <*> is obviously exceptionally useful in practice. But liftA2 seems like the > more essential shape of that operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 04:32:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 04:32:50 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages Message-ID: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- The following code results in a confusing/wrong error message, blaming a type variable (`a`) being a fixed Skolem variable: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE PolyKinds #-} data I a type family F x type instance F (I a) = a identity :: F (I a) -> F (I a) identity x = x }}} with the error message {{{ • Couldn't match type ‘F (I a0)’ with ‘F (I a)’ Expected type: F (I a) -> F (I a) Actual type: F (I a0) -> F (I a0) NB: ‘F’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘identity’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: identity :: F (I a) -> F (I a) | 9 | identity :: F (I a) -> F (I a) | ^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 06:38:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 06:38:30 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.4c7d09ac14d4be2efba7d7af8ecd5765@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): It worked! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 08:31:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 08:31:48 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? Message-ID: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> #13193: Integer (gmp) performance regression? -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- For a simple program that uses Integer, but actual data would fit in an Int, ghc-8.0.2 seems to have more runtime overhead than ghc-6.12.3 had: http://www.imn.htwk-leipzig.de/~waldmann/etc/mob/ I am not really sure what to make of it - an answer could be: "if you know that your Integer fits in an Int, then just use Int". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 08:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 08:41:51 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.3cafdf53891cb5d2f71fc54790899b4b@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): For what level of `n`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 08:47:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 08:47:33 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.a6b2aef23cb48951ce83393e192943e6@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): it works with 1000, I can bisect to see the first value that makes it work -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 09:11:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 09:11:01 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.febe8068fc9194cdba87ebff94b78b7c@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: 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 simonpj): That's odd * Can you explain how to reproduce the performance change you see? * Can you say how big the perf change is? * Can you say why you think it's tied up with "does your Integer fit into an Int"? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 09:17:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 09:17:02 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.e5bb433961fa5989fb657f2bc0a2cd68@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): 103 is bad, 104 is good -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 09:20:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 09:20:46 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.a54424039b3301134d43a38cb17328fb@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * milestone: => 8.2.1 Comment: As I (`christiaanb` on IRC) have several type-checker plugins released on Hackage, I would like to see a fix for this included in the GHC 8.2.1 release. I've already asked Adam Gundry for some guidance in helping me fix it. Although I surely wouldn't mind if someone with more familiarity with the affected part of the codebase could work out a fix for this bug instead ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 10:18:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 10:18:24 -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.85403014a7322ef064418d02c9df64af@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 simonpj): Thanks Peter. So, what should we do to solve it? It's a bad (cubic), unexpected, and unpredictable performance hole. Could you perhaps work on a fix? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 10:25:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 10:25:39 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.b1de08a5e0fc38c62e5570c3931230ca@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: 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 j.waldmann): Hi. * how to reproduce: add the type declaration that prevents the defaulting {{{ a :: Int -> ST s Int -> ST s Int -> ST s Int -> ST s Int -> ST s Int -> ST s Int` }}} * how big the change is {{{ ghc-6.12.3: Int: 1.28 sec Integer: 1.56 sec ghc-8.0.2 : Int: 1.30 sec Integer: 2.30 sec }}} * "Integer fit in Int" - when I replace Integer by Int, the program produces the exact same result, so I assume there were no overflows. When I replace the numerals 1, -1 by something really large (+/- 1000000000000000000), the execution path should be identical (affine transformation). The Int result does no longer agree with the Integer result, and the Integer runtime goes up slightly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 10:30:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 10:30:06 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.2eb56411e10a99720a8446c1e3113723@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: 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 simonpj): So to paraphase: the difference between Int and Integer perf for 6.10 is smaller than 8.0. Thanks. Does anyone feel able to take a few minutes to dig into why this is the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 10:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 10:35:45 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.bb291bbaf3e1c804d1b16c32dea99760@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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 11:12:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 11:12:19 -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.6baf60af4ae567c5ee54ba6458b33261@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 scpmw): I think dfeuer has managed to identify the core of the issue, so the hard work should be done. As I sketched there are a good number of options for how to fix it, and we could even fall back to special handling for deeply nested constructors with tick annotations in CorePrep if the more elegant approaches turn out not to work. I'll put some time into it over the weekend if nobody else grabs it first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 11:28:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 11:28: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.d2a3ddb5c71004cdab9ba2a35d22c7c3@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry, simonpj (added) * keywords: => UndecidableSuperClasses, plugin Comment: Thanks for pointing me to this bug. The problem would appear to be the `UndecidableSuperClasses` changes in 6eabb6ddb7c53784792ee26b1e0657bde7eee7fb, which introduced a new `expandSuperClasses` step after the `solveSimpleWanteds` loop. This is the step that looks for `CDictCan`, and hence fails to expand the constraint because the plugin-induced zonking has turned it into a `CNonCanonical` instead. I think the right way to fix this is to change `zonkCt` so that it preserves `CDictCan`, much as it already preserves `CHoleCan`. We want to zonk before running the plugins, as otherwise the plugins will have to expand mutable type variables themselves. I suspect that we shouldn't modify `expandSuperClasses` to look for `CNonCanoical` dictionaries, because it passes around information in the `cc_pend_sc` field of `CDictCan`. The code has changed quite a bit since I last looked at it, however, so it might be worth checking with someone more knowledgeable than me (simonpj?) if this makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 11:33:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 11:33:09 -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.c59118140b19be43c4b7c474ae7491c9@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you Adam. I'm deeply swamped all this week and most of next. Could you articulate in a bit more detail, starting from zero, what the problem is, and why zonking `CDictCan` differently would help? Then I'll try to respond. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 12:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 12:08:12 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.52fcfd4baad40f192b367815c0f49cb2@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | 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): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't know much about JSON but the basic idea seems good. This is just for error messages, right, not for (say `-ddump-simpl`)? Perhaps `-ddump-X` isn't the right connotation. Maybe `-djson-errors`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 12:55:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 12:55:07 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.ecdd9a86ac2e7dd829935162507a7ddb@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | 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): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:1 simonpj]: > I don't know much about JSON but the basic idea seems good. > > This is just for error messages, right, not for (say `-ddump-simpl`)? All compiler output will be formatted as structured JSON. The consumer can filter out logging messages from -ddump-simpl output from warnings as they desire. This information is tracked in the `Severity` argument. > > Perhaps `-ddump-X` isn't the right connotation. Maybe `-djson-errors`? That much is up for discussion. It is named this way as it hooks into the same machinery which controls `-ddump-to-file` and related flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 13:03:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 13:03:31 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.20a441b2be40afc457f69eaf11868721@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | 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): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > All compiler output will be formatted as structured JSON Including the output of `-dverbose-core2core`, `-ddump-types` etc etc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 13:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 13:45:06 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages In-Reply-To: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> References: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> Message-ID: <065.635921f56de27c3741309a0e935042f4@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): To add more information: this code is accepted without `PolyKinds`, because `F (I a)` can immediately reduce to `a`. With `PolyKinds`, `F (I a)` is stuck, as we don't know `a`'s kind. (The equation for `F` works only when `(a :: Type)`.) Perhaps the best fix is to add a check in !TcErrors for type families that match on invisible parameters (i.e., kinds) and emit a {{{NB: Type family `F' has equations that depend on the kind of its argument(s)}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 13:45:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 13:45:34 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.6a8b4c2bbecfc656e6c833da75ddfea7@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | 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): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes but if you don't want those outputted as json then you can turn off these flags. This actually caught a bug in my implementation as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 14:40:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 14:40:56 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages In-Reply-To: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> References: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> Message-ID: <065.314d775fb0dd60bf3e23d3790d3844cf@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Why does it also not work if I change the definition of `F` to {{{ type family F (x :: *) :: k }}} in which case ghci tells me the instance is {{{ type instance F k (I k a) = a -- Defined at I.hs:7:16 }}} but ghc gives the same error regarding `identity`. Is `k` not determined by the result kind of the type family, i.e., the fact that `F (I a)` appears as a type argument to `(->)`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 14:47:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 14:47: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.fbe205190e7fdc6665de9dde6a2d332a@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Okay, let me try to summarise: 1. When a type-checker plugin is in use, we zonk the constraints before calling the plugin. Thus plugins don't need to worry about doing their own zonking. 2. Zonking a `CDictCan` constraint (or indeed anything other than a `CHoleCan`) turns it into a `CNonCanonical`. Presumably this is because zonking may not preserve the invariants of all the canonical constraints, so they might need to be re-canonicalized if they are looked at again later. 3. The `expandSuperClasses` step, which runs after the simple wanted and plugin loop, looks for `CDictCan`s. If a plugin is in use, 1 and 2 mean that it doesn't find any, and hence fails to expand superclasses. This leads to the solving failure reported in this ticket. If we can make `zonkCt` preserve `CDictCan` rather than turning it into `CNonCanonical`, then `expandSuperClasses` should just work even in the presence of plugins. However, it isn't completely obvious to me whether the invariants of `CDictCan` (e.g. the fact that `cc_tyargs` is "function- free") will still hold after zonking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 14:48:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 14:48:19 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.da51cbb2142d1b411ed720615d0063f3@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): Is this related -- http://stackoverflow.com/questions/41896211/how-to-use- packageimports-extension-to-shadow-a-module ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 14:52:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 14:52:40 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.7109bad54d53c72268af093dbda69852@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): What's the easiest way to get the following in GHCi? * List of all modules exported by a package * List of all names exported by a module -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 15:09:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 15:09:57 -0000 Subject: [GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports In-Reply-To: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> References: <050.205c0cc1b6cde3d2b797a3216b4e5c29@haskell.org> Message-ID: <065.81fbafef480768e171bff93bc702205c@haskell.org> #13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5979 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): * I don't think there is a command to do this in GHCi specifically. I would use `ghc-pkg describe ` or `ghc-pkg field exposed- modules`. * Use `:browse Data.List`, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 15:12:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 15:12:20 -0000 Subject: [GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char In-Reply-To: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> References: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> Message-ID: <065.ff423582f432fd13aa77fa292a8b1c2c@haskell.org> #13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3033 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3033 * milestone: => 8.2.1 Comment: I like the idea of turning it into a `WARN`. I've done so in Phab:D3033, and refactored that comment below it a bit. Does this look OK? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 15:12:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 15:12:53 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages In-Reply-To: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> References: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> Message-ID: <065.1031eac29775e1def5ea942a5bd95e18@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you explain more precisely why `F (I a)` is stuck with `PolyKinds`? I don't get it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 15:14:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 15:14:24 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.3ce956321145ee1e1fb2d7d4884770b2@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | 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): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Another possible design is that all output is formatted as JSON and then it is the tools responsibility to forwards messages on stdout as normal if desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 15:26:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 15:26:11 -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.c682993f2b26180b348242a3e8abaab8@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh, (3) is terrible! It's find just to elaborate `zonkCt`. Constraints are always re-flattened etc even if they come in as `CDictCan`. Only canonical constraints that are actually ''in the inert set'' carry all the guarantees. That point should be more carefully documented, I agree. It's a bit more code to do this (which is, I think, why `zonkCt` currently always returns a `CNonCanonical`), so please include a Note to explain. Also * `CTyEqCan`: flattening the LHS might not give a type variable; if not, return a `CNonCanonical`. * `CFunEqCan`: you could do the same for the `cc_fsk` field, but I don't think `zonkCt` should ever encounter a `CFunEqCan`, because the latter are removed by `TcFlatten.unflatten`. So you could just crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 16:40:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 16:40:05 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages In-Reply-To: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> References: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> Message-ID: <065.1c797b1590c5e2d086afd3fc7307d1da@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): In the original program, the application `F (I a)` is stuck because * `data I a` really means `data I k (a :: k) :: *`, i.e., `I` is polykinded * `type family F x` really means `type family F k (x :: *) :: *`, i.e., `F` is ''not'' polykinded * `type instance F (I a) = a` really means `type instance F (I * a) = a`, because the instance is only well-kinded when `a` has kind `*`. But there's nothing stopping one from adding an additional instance `type instance F (I Maybe) = Char` which uses `I` at a different kind. * `identity :: F (I a) -> F (I a)` really means `identity :: forall k (a :: k). F (I k a) -> F (I k a)`, i.e., `identity` is polykinded. Now there's a problem because the instance we defined only applies when `k = *`, but here `k` could really be anything, like `* -> *`. And indeed if I added the `type instance F (I Maybe) = Char`, then I can write `identity @ Maybe` and it has type `Char -> Char` just like `identity @ Char` does. So the type really is ambiguous. What I'm confused about is why `F (I a)` is still stuck even when I make the result of `F` polykinded, so that the instance `type instance F (I a) = a` applies at all kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 16:42:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 16:42:38 -0000 Subject: [GHC] #13194: Concurrent modification of package.cache is not safe Message-ID: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> #13194: Concurrent modification of package.cache is not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- There are a couple of different issues here. 1. On Linux, issuing `ghc-pkg register` for multiple packages in parallel might result in lost updates to package database because of how `registerPackage` function works - it reads existing package databases, picks the one to modify, then checks that package info for the package to register is fine and replaces package database with what was read in the beginning + new package info. Therefore, if updates interleave, it might happen that process1 reads the database, then process2 updates it while process1 still has the old version and uses it for its update later, so update made by process2 is lost. 2. On Windows, update to package database might fail - the issue is that GHC attempts to update it using rename trick, which fails whenever any other process has file to be replaced open for reading. Combine that with the fact that GHC reads package database when compiling packages and you get problems in both Stack (https://github.com/commercialhaskell/stack/issues/2617) and Cabal (https://github.com/haskell/cabal/issues/4005). BTW, rename trick (used for atomic database updates) not only doesn't work on Windows, it's also not atomic e.g. on NFS (https://stackoverflow.com/questions/41362016/rename-atomicity-and-nfs). The solution to both problems is to use OS specific features to lock database file (in shared mode when reading and in exclusive mode when writing). This can be done on Windows using LockFileEx. Unfortunately for POSIX things are a bit more complicated. There are two ways to lock a file on Linux: 1. Using fcntl(F_SET_LK) (POSIX API) 2. Using flock (BSD API) However, fcntl locks have a serious limitation: The record locks described above are associated with the process (unlike the open file description locks described below). This has some unfortunate consequences: * If a process closes any file descriptor referring to a file, then all of the process's locks on that file are released, regardless of the file descriptor(s) on which the locks were obtained. This is bad: it means that a process can lose its locks on a file such as /etc/passwd or /etc/mtab when for some reason a library function decides to open, read, and close the same file. * The threads in a process share locks. In other words, a multithreaded program can't use record locking to ensure that threads don't simultaneously access the same region of a file. Whereas flock is not guaranteed to work with NFS, according to https://en.wikipedia.org/wiki/File_locking#Problems: Whether and how flock locks work on network filesystems, such as NFS, is implementation dependent. On BSD systems, flock calls on a file descriptor open to a file on an NFS-mounted partition are successful no-ops. On Linux prior to 2.6.12, flock calls on NFS files would act only locally. Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte-range locks. These locks will be visible to other NFS clients that implement fcntl-style POSIX locks, but invisible to those that do not.[4] Assuming that the solution would be to go with locking the database, we would need to: 1. In `registerPackage`, lock all read databases in shared mode except for the database that will later be modified, which has to be locked in exclusive mode. The handle also would need to be kept open and passed to `changeDB` later and used for rewriting the database with updated version in `GHC.PackageDb.writePackageDb` instead of `writeFileAtomic` (which is not actually unconditionally atomic, as demonstrated above). 2. `GHC.PackageDb.decodeFromFile` would lock a file in appropriate mode and return the handle to open file if appropriate. 3. Add support for locking a file. This should be fairly easy to do in GHC.IO.Handle.FD by extending function `openFile'` with appropriate parameters and then adding wrapper function `openLockedFile` or something. We can add both blocking and non-blocking locking to make ghc-pkg show information about waiting for locked package database if appropriate. Alternatively we could add a function similar to the following: `hLock :: Handle -> LockMode -> Bool{-block-} -> IO Bool`, but that requires extracting file descriptor from Handle, which as far as I see is problematic. Is going with locking an acceptable solution here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 16:46:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 16:46:12 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe (was: Concurrent modification of package.cache is not safe) In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.d6d5dd203c764be46cb4b775b054012f@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 16:55:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 16:55:33 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.a3710e799d50760bc12af48f39f0f048@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): The allocations go up between 7.8 and 7.10, so I'm sure it has to do with the new integer-gmp library in 7.10. Will take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:08:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:08:37 -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.4b73b4ac335ddea1ee9c07d1e9c465a0@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: 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: | -------------------------------------+------------------------------------- Comment (by duncan): The `fnctl` semantics is problematic in general but not for our use case for ghc/ghc-pkg with the package.conf file. Making a general reusable API is nice, but not essential. The `flock` API is probably the one to go with, despite NFS issues. As for a suitable API, either internal or for more general consumption, the API presented by the filelock is a useful place to start (and it has good code we can borrow for the FFI bits). My first guess is that a reasonable route to try is to go with a `Handle` based API, like {{{ hLockFile :: Handle -> LockMode -> IO FileLock hTryLockFile :: Handle -> LockMode -> IO (Maybe FileLock) hUnlockFile :: Handle -> FileLock -> IO () withFileLock :: Handle -> LockMode -> (FileLock -> IO a) -> IO a }}} I'm not yet totally clear what lives in the `FileLock`. Is this for the sake of the Win32 API because it returns a lock handle? And perhaps `hUnlockFile` doesn't need the `Handle` too. > but that requires extracting file descriptor from Handle, which as far as I see is problematic. It's actually totally possible. It simply fails for Handles that are not based on FDs, but that's ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:35:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:35:40 -0000 Subject: [GHC] #13195: Ticks panic Message-ID: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> #13195: Ticks panic -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Preprocessing test suite 'tests' for url-decoders-1... [1 of 1] Compiling Main ( tests/Main.hs, dist/build/tests /tests-tmp/Main.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone withForeignPtr1 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 144969 }}} To reproduce the but, clone a repo under the specified commit from the following URL: https://github.com/nikita-volkov/url- decoders/tree/22410402a41b7524a1af03d78e381e9ea6354944 Then run the following command on the project: {{{ cabal configure --enable-tests && cabal build --ghc-options=-O2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:40:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:40:54 -0000 Subject: [GHC] #13195: Ticks panic In-Reply-To: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> References: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> Message-ID: <062.345a27ba054c8e37361de1979e387fb5@haskell.org> #13195: Ticks panic -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | 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): How high do you have to increase the tick factor to make it compile? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:44:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:44:00 -0000 Subject: [GHC] #13195: Ticks panic In-Reply-To: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> References: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> Message-ID: <062.c8900dbc363ad5c7f7afddba7a607e64@haskell.org> #13195: Ticks panic -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | 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 mojojojo): 200 seems enough -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:44:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:44:26 -0000 Subject: [GHC] #13195: Ticks panic In-Reply-To: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> References: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> Message-ID: <062.cbf2cd681b1f9b60eb72a986a7d303d1@haskell.org> #13195: Ticks panic -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | 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): I also note that every definition in the library is marked as INLINE so it perhaps not surprising that the inliner is working hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:47:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:47:25 -0000 Subject: [GHC] #13195: Ticks panic In-Reply-To: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> References: <047.55abe96d5a9c88411d33c23d2fd863ae@haskell.org> Message-ID: <062.d8c294b962566038532b41ddcb3ec6d8@haskell.org> #13195: Ticks panic -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | 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 mojojojo): Yes. Tinkering with inlinings also makes the bug disappear, however it also reduces the runtime performance. Either way, the compiler itself states that it is a compiler bug, hence I'm reporting it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 17:48:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 17:48:03 -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.24358503c404a37923dcf88118710cd1@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => highest * owner: => dfeuer * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 18:18:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 18:18:13 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.348bd15b9ce892192c3519b8ec6ec0e2@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): Yes, the additional allocations do have to do with the new integer-gmp, though they aren't entirely the integer-gmp library's fault. The additional allocations occur in subtraction (in `pred`). {{{ -- | Subtract one 'Integer' from another. minusInteger :: Integer -> Integer -> Integer minusInteger x (S# 0#) = x minusInteger (S# 0#) (S# INT_MINBOUND#) = Jp# (wordToBigNat ABS_INT_MINBOUND##) minusInteger (S# 0#) (S# y#) = S# (negateInt# y#) minusInteger (S# x#) (S# y#) = case subIntC# x# y# of (# z#, 0# #) -> S# z# (# 0#, _ #) -> Jn# (wordToBigNat2 1## 0##) (# z#, _ #) | isTrue# (z# ># 0#) -> Jn# (wordToBigNat ( (int2Word# (negateInt# z#)))) | True -> Jp# (wordToBigNat ( (int2Word# z#))) -- more cases, that aren't (S# _) (S# _) }}} Based on looking at the assembly, this seems to have been compiled in 7.10.1 to something like {{{ minusInteger x y = case y of { S# y# -> case y# of { 0# -> ... INT_MINBOUND# -> ... __DEFAULT__ -> let minusY = S# (negateInt# y#) in case x of { S# x# -> ... Jp# {} -> ... Jn# {} -> ... } } Jp# {} -> ... Jn# {} -> ... } }}} Note that we allocate `S# (negateInt# y#)` even though we're unlikely to actually need it, and will never need it more than once. I see two issues here: * There are many special cases in `minusInteger`, that are almost never helpful, and harmful in the common case of small integers (i.e., `S#`). The old code which began {{{ minusInteger (S# i) (S# j) = case subIntC# i j of ... }}} was much better. But, by itself this shouldn't cause additional ''allocations'', just additional work in the form of conditionals and branches. * GHC floated out `S# (negateInt# y#)`, which was a bad choice: increased allocations, and never any gain, as far as I can see. Aha, now that I look at the rest of `minusInteger`, `(negateInt# y#)` does appear again in some branches like {{{ minusInteger (Jp# x) (S# y#) | isTrue# (y# >=# 0#) = bigNatToInteger (minusBigNatWord x (int2Word# y#)) | True = Jp# (plusBigNatWord x (int2Word# (negateInt# y#))) }}} But it's never used more than once per branch, and the `S#` box that we allocated is still not used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 20:24:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 20:24:50 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.8354b0c426ef7d1f879fd93d4c67bbb5@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): Aha! the source code I was looking at changed since the version of the object code I was examining. So disregard the second point above. Phab:D2278 is new in HEAD; the old implementation was basically `x - y = x + (-y)`, which has to allocate `-y`. I think the code could still be made somewhat shorter/better, but that would be a relatively minor improvement. j.waldmann, could you test with a perf build of HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 20:29:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 20:29:39 -0000 Subject: [GHC] #13196: Document AMP as a deviation from Haskell 2010 Message-ID: <045.1f8df52ab9422d8ec9fe4222a7eecbbc@haskell.org> #13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 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: -------------------------------------+------------------------------------- The `Applicative` class is not in Haskell 2010, and is certainly not a superclass of `Monad` there. This must be documented as a deviation in the user's guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 20:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 20:29: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.f267c892df7491ea950f59c6830f6af7@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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 20:59:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 20:59:08 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.39612b822ae834674e5bbf67295f0667@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: 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): > I just noticed that this means that you do not get deadlock detection if you forkIO (forever (threadDelay 100000)). That's interesting. Probably because it never runs a major GC, only minor GCs. Admittedly that's surprising and counter-intuitive. > I do care that interactive programs I'm not actively using don't consume 12% of my CPU. I'm sympathetic to that. Like I said, I'm open to suggestions here. I do worry that not having deadlock detection by default will be surprising - it's quite useful when developing/debugging, for instance. We have lots of tests in `testsuite/tests/concurrent` that rely on it. How about we give the idle GC a time budget expressed as a % of wall clock time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 21:33:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 21:33:16 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages In-Reply-To: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> References: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> Message-ID: <065.103091f66571665a73ec333d7192b00f@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The type instance in @rwbarton's case expands to `F k (I k a) = a`. This instance requires the two `k`s to be the same. In `identity`'s type signature, we get `F (TYPE r) (I k a) -> F (TYPE r') (I k a)`. GHC (rightly) doesn't know that `k` and `TYPE r` are the same. (The fact that it's `TYPE r` and not `Type` is ''not'' the issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 22:29:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 22:29:47 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.b70bbf3cfeb76195e31524e9cd90dbfe@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): Since I spent all that time looking at the wrong version of `minusInteger` anyways, I went ahead and simlified it slightly: Phab:D3034. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 23:17:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 23:17:31 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.848a4b7396618a61bd0086046413f53e@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 simonpj): Thanks for working on this. If you think that HEAD is compiling code that is sub-optimal, can you boil it out to an example? But if it is just that the original Haskell forces GHC to generate bad code, then yes let's just improve the implementation of `minusInteger`. I couldn't quite figure out which is the case from the notes above. I did try to compile the code from comment:6. For the record, here's what I compiled; and it seemed to give good code (no allocation) {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Foo where import Prelude () import GHC.Classes import GHC.Magic import GHC.Prim import GHC.Types #if WORD_SIZE_IN_BITS < 64 import GHC.IntWord64 #endif #define INT_MINBOUND -300 #define ABS_INT_MINBOUND 300 wordToBigNat :: Word# -> BigNat wordToBigNat x = 7 wordToBigNat2 :: Word# -> Word# -> BigNat wordToBigNat2 _ lw# = 3 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 type BigNat = Int -- | Subtract one 'Integer' from another. minusInteger :: Integer -> Integer -> Integer minusInteger x (S# 0#) = x minusInteger (S# 0#) (S# INT_MINBOUND#) = Jp# (wordToBigNat ABS_INT_MINBOUND##) minusInteger (S# 0#) (S# y#) = S# (negateInt# y#) minusInteger (S# x#) (S# y#) = case subIntC# x# y# of (# z#, 0# #) -> S# z# (# 0#, _ #) -> Jn# (wordToBigNat2 1## 0##) (# z#, _ #) | isTrue# (z# ># 0#) -> Jn# (wordToBigNat ( (int2Word# (negateInt# z#)))) | True -> Jp# (wordToBigNat ( (int2Word# z#))) -- more cases, that aren't (S# _) (S# _) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 27 23:52:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jan 2017 23:52:07 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.4b44d57a3156a7afa97857c1f19eb401@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): Replying to [comment:9 simonpj]: > Thanks for working on this. If you think that HEAD is compiling code that is sub-optimal, can you boil it out to an example? But if it is just that the original Haskell forces GHC to generate bad code, then yes let's just improve the implementation of `minusInteger`. > > I couldn't quite figure out which is the case from the notes above. Please disregard the second bullet point of comment:6. I was comparing compiled code from 7.10 with the source code from HEAD, but there was a change that I didn't know about in the source between those versions. My hope is that this change (Phab:D2278 from this past May) will bring HEAD's performance back in line with 7.8's, but I don't have a suitable setup to test that at the moment. If it does so then we can close this ticket (optionally: after landing Phab:D3034, improving the implementation of `minusInteger` slightly). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 02:54:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 02:54:50 -0000 Subject: [GHC] #13197: Perplexing levity polymorphism issue Message-ID: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> #13197: Perplexing levity polymorphism issue -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- I would have expected this to compile since the levity polymorphism patch was merged, but sadly it seems the typechecker isn't quite clever enough yet (or perhaps I'm the not clever one), {{{#!hs {-# LANGUAGE GADTs, PolyKinds, PatternSynonyms, RankNTypes, TypeOperators, ViewPatterns #-} {-# LANGUAGE TypeInType #-} module Test where import Data.Kind import GHC.Exts data TypeRep (a :: k) where TypeCon :: String -> TypeRep a TypeApp :: forall k1 k2 (f :: k1 -> k2) (x :: k1). TypeRep f -> TypeRep x -> TypeRep (f x) TypeFun :: forall r1 r2 (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) data SomeTypeRep where SomeTypeRep :: forall k (a :: k). TypeRep a -> SomeTypeRep data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a eqTypeRep :: TypeRep (a :: k1) -> TypeRep (b :: k2) -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall (k :: *). forall (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined toApp :: SomeTypeRep -> SomeTypeRep -> Maybe SomeTypeRep toApp (SomeTypeRep f) (SomeTypeRep a) | TypeFun arg res <- typeRepKind f , Just HRefl <- arg `eqTypeRep` typeRepKind a = Just $ SomeTypeRep (TypeApp f a) toApp _ _ = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 03:38:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 03:38:34 -0000 Subject: [GHC] #13198: incorrect links and file names in GHC user's guide Message-ID: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> #13198: incorrect links and file names in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- There are some incorrect links and file names in GHC user's guide. * docs/users_guide/glasgow_exts.rst - GHC/Base.lhs - GHC/List.lhs * docs/users_guide/ffi-chap.rst - :base-ref:`Foreign` - :base-ref:`Control.Concurrent` I'll send the patch soon on phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 03:39:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 03:39:42 -0000 Subject: [GHC] #13197: Perplexing levity polymorphism issue In-Reply-To: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> References: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> Message-ID: <061.582aaf17de12fb1fd37bde4b500c0e17@haskell.org> #13197: Perplexing levity polymorphism issue -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -2,2 +2,2 @@ - was merged, but sadly it seems the typechecker isn't quite clever enough - yet (or perhaps I'm the not clever one), + (along with Phab:D2038) was merged, but sadly it seems the typechecker + isn't quite clever enough yet (or perhaps I'm the not clever one), New description: I would have expected this to compile since the levity polymorphism patch (along with Phab:D2038) was merged, but sadly it seems the typechecker isn't quite clever enough yet (or perhaps I'm the not clever one), {{{#!hs {-# LANGUAGE GADTs, PolyKinds, PatternSynonyms, RankNTypes, TypeOperators, ViewPatterns #-} {-# LANGUAGE TypeInType #-} module Test where import Data.Kind import GHC.Exts data TypeRep (a :: k) where TypeCon :: String -> TypeRep a TypeApp :: forall k1 k2 (f :: k1 -> k2) (x :: k1). TypeRep f -> TypeRep x -> TypeRep (f x) TypeFun :: forall r1 r2 (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) data SomeTypeRep where SomeTypeRep :: forall k (a :: k). TypeRep a -> SomeTypeRep data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a eqTypeRep :: TypeRep (a :: k1) -> TypeRep (b :: k2) -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall (k :: *). forall (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined toApp :: SomeTypeRep -> SomeTypeRep -> Maybe SomeTypeRep toApp (SomeTypeRep f) (SomeTypeRep a) | TypeFun arg res <- typeRepKind f , Just HRefl <- arg `eqTypeRep` typeRepKind a = Just $ SomeTypeRep (TypeApp f a) toApp _ _ = Nothing }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 03:44:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 03:44:29 -0000 Subject: [GHC] #13197: Perplexing levity polymorphism issue In-Reply-To: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> References: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> Message-ID: <061.6ac3c294b01d4d71ac5f2297a4cb7cde@haskell.org> #13197: Perplexing levity polymorphism issue -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record the above fails with, {{{ Test.hs:34:33: error: • Could not deduce: (r2 :: RuntimeRep) ~~ ('LiftedRep :: RuntimeRep) from the context: ((* :: *) ~~ (* :: *), (k :: *) ~~ ((a2 -> b) :: *)) bound by a pattern with constructor: TypeFun :: forall (a :: TYPE r1) (b :: TYPE r2). TypeRep (TYPE r1) a -> TypeRep (TYPE r2) b -> TypeRep * (a -> b), in a pattern binding in pattern guard for an equation for ‘toApp’ at Test.hs:32:5-19 or from: ((* :: *) ~~ (TYPE r1 :: *), (k1 :: *) ~~ (a2 :: TYPE r1)) bound by a pattern with constructor: HRefl :: forall k2 (a :: k2). (:~~:) k2 k2 a a, in a pattern binding in pattern guard for an equation for ‘toApp’ at Test.hs:33:10-14 ‘r2’ is a rigid type variable bound by a pattern with constructor: TypeFun :: forall (a :: TYPE r1) (b :: TYPE r2). TypeRep (TYPE r1) a -> TypeRep (TYPE r2) b -> TypeRep * (a -> b), in a pattern binding in pattern guard for an equation for ‘toApp’ at Test.hs:32:5-19 When matching the kind of ‘b’ Expected type: TypeRep (k1 -> b) a Actual type: TypeRep k a • In the first argument of ‘TypeApp’, namely ‘f’ In the first argument of ‘SomeTypeRep’, namely ‘(TypeApp f a)’ In the second argument of ‘($)’, namely ‘SomeTypeRep (TypeApp f a)’ • Relevant bindings include res :: TypeRep (TYPE r2) b (bound at Test.hs:32:17) | 34 | = Just $ SomeTypeRep (TypeApp f a) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 03:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 03:59:49 -0000 Subject: [GHC] #13197: Perplexing levity polymorphism issue In-Reply-To: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> References: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> Message-ID: <061.93be7afce150d0eab74524d635cabf86@haskell.org> #13197: Perplexing levity polymorphism issue -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): This is expected behavior. Well, for me. After I've studied it and revised my expectation. The problem is that `k2` in the type of `TypeApp` has kind `Type`. But `f a`'s kind, `res`, has type `TYPE r2`, which we see looking at the type of `TypeFun`. So we get a type error. The fix is to convince GHC that `f a`'s type's kind is really `Type`. And we can do that with one extra check: {{{ toApp :: SomeTypeRep -> SomeTypeRep -> Maybe SomeTypeRep toApp (SomeTypeRep f) (SomeTypeRep a) | TypeFun arg res <- typeRepKind f , Just HRefl <- arg `eqTypeRep` typeRepKind a , Just HRefl <- typeRepKind res `eqTypeRep` (undefined :: TypeRep Type) = Just $ SomeTypeRep (TypeApp f a) toApp _ _ = Nothing }}} This compiles for me. Note that `arg`'s kind is discovered to be `Type` because `arg` equals the result of a `typeRepKind`, which always has kind `Type`. Fun times! GHC should really come little trophies that you can accrue by triggering certain bizarre scenarios. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:01:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:01:11 -0000 Subject: [GHC] #13197: Perplexing levity polymorphism issue In-Reply-To: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> References: <046.a382bbafceef52d0badd08cb4d53b027@haskell.org> Message-ID: <061.56b9a031867574fb3d82d35d5992f92e@haskell.org> #13197: Perplexing levity polymorphism issue -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: invalid | 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 goldfire): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:18:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:18:02 -0000 Subject: [GHC] #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 Message-ID: <050.b044bfecf56f5eb671b9f81c21e00b95@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The HsSyn prettyprinter tests patch 499e43824bda967546ebf95ee33ec1f84a114a7c broke the pretty-printing of Template Haskell-spliced class instances. You can see this for yourself by compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where class C a b $([d| instance C a (Maybe b) |]) }}} {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.1.20170126: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(9,3)-(10,6): Splicing declarations [d| instance C a_a1eC (Maybe b_a1eD) |] ======> instance C a_a4m5 Maybe b_a4m6 }}} Note the nonsensical `instance C a_a4m5 Maybe b_a4m6`. For comparison, here is how it should be pretty-printed: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(9,3)-(10,6): Splicing declarations [d| instance C a_a13N (Maybe b_a13O) |] ======> instance C a_a3Ju (Maybe b_a3Jv) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:18:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:18:14 -0000 Subject: [GHC] #13198: incorrect links and file names in GHC user's guide In-Reply-To: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> References: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> Message-ID: <062.a3f4914e72516bc80ca0f8c0b17a0e4d@haskell.org> #13198: incorrect links and file names in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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): Phab:D3035 Wiki Page: | -------------------------------------+------------------------------------- Changes (by takenobu): * status: new => patch * differential: => Phab:D3035 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:23:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:23:46 -0000 Subject: [GHC] #13162: Testsuite driver has problems reliably removing files In-Reply-To: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> References: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> Message-ID: <059.2a55840291f60243054cc04df616ac35@haskell.org> #13162: Testsuite driver has problems reliably removing files -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2936 Wiki Page: | -----------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"1f366b8d15feaa05931bd2d81d8b0c5bae92f3b8/ghc" 1f366b8d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f366b8d15feaa05931bd2d81d8b0c5bae92f3b8" Add delete retry loop. [ci skip] Summary: On Windows we have to retry the delete a couple of times. The reason for this is that a `FileDelete` command just marks a file for deletion. The file is really only removed when the last handle to the file is closed. Unfortunately there are a lot of system services that can have a file temporarily opened using a shared readonly lock, such as the built in AV and search indexer. We can't really guarantee that these are all off, so what we can do is whenever after a `rmtree` the folder still exists to try again and wait a bit. Based on what I've seen from the tests on CI server, is that this is relatively rare. So overall we won't be retrying a lot. If after a reasonable amount of time the folder is still locked then abort the current test by throwing an exception, this so it won't fail with an even more cryptic error. The issue is that these services often open a file using `FILE_SHARE_DELETE` permissions. So they can seemingly be removed, and for most intended purposes they are, but recreating the file with the same name will fail as the FS will prevent data loss. The MSDN docs for `DeleteFile` says: ``` The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. ``` Retrying seems to be a common pattern, SQLite has it in their driver http://www.sqlite.org/src/info/89f1848d7f The only way to avoid this is to run each way of a test in it's own folder. This would also have the added bonus of increased parallelism. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2936 GHC Trac Issues: #12661, #13162 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:23:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:23:46 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.94122ba47a57bfd2b48e62cc08eb4a26@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Tamar Christina ): In [changeset:"1f366b8d15feaa05931bd2d81d8b0c5bae92f3b8/ghc" 1f366b8d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f366b8d15feaa05931bd2d81d8b0c5bae92f3b8" Add delete retry loop. [ci skip] Summary: On Windows we have to retry the delete a couple of times. The reason for this is that a `FileDelete` command just marks a file for deletion. The file is really only removed when the last handle to the file is closed. Unfortunately there are a lot of system services that can have a file temporarily opened using a shared readonly lock, such as the built in AV and search indexer. We can't really guarantee that these are all off, so what we can do is whenever after a `rmtree` the folder still exists to try again and wait a bit. Based on what I've seen from the tests on CI server, is that this is relatively rare. So overall we won't be retrying a lot. If after a reasonable amount of time the folder is still locked then abort the current test by throwing an exception, this so it won't fail with an even more cryptic error. The issue is that these services often open a file using `FILE_SHARE_DELETE` permissions. So they can seemingly be removed, and for most intended purposes they are, but recreating the file with the same name will fail as the FS will prevent data loss. The MSDN docs for `DeleteFile` says: ``` The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. ``` Retrying seems to be a common pattern, SQLite has it in their driver http://www.sqlite.org/src/info/89f1848d7f The only way to avoid this is to run each way of a test in it's own folder. This would also have the added bonus of increased parallelism. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2936 GHC Trac Issues: #12661, #13162 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:25:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:25:18 -0000 Subject: [GHC] #13162: Testsuite driver has problems reliably removing files In-Reply-To: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> References: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> Message-ID: <059.1209e2e6d6f4009cbcaa7aa15c70b71f@haskell.org> #13162: Testsuite driver has problems reliably removing files -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2936 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:25:31 -0000 Subject: [GHC] #13162: Testsuite driver has problems reliably removing files In-Reply-To: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> References: <044.f22c582cdc4a9414dda161f80dcf5f72@haskell.org> Message-ID: <059.dd2dd288c402bb50fa5d04633f4fc24a@haskell.org> #13162: Testsuite driver has problems reliably removing files -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2936 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 04:44:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 04:44:43 -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.cb7287daa15b4e05e2cd4becde1e6470@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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 RyanGlScott): This change was triggered by [http://git.haskell.org/ghc.git/blobdiff/83d69dca896c7df1f2a36268d5b45c9283985ebf..499e43824bda967546ebf95ee33ec1f84a114a7c:/compiler/hsSyn/HsTypes.hs this modification] in `HsTypes`: {{{#!diff diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs index 6d82f92..e3e5246 100644 (file) --- a/compiler/hsSyn/HsTypes.hs +++ b/compiler/hsSyn/HsTypes.hs @@ -1279,13 +1313,11 @@ ppr_mono_ty ctxt_prec (HsEqTy ty1 ty2) = maybeParen ctxt_prec TyOpPrec $ ppr_mono_lty TyOpPrec ty1 <+> char '~' <+> ppr_mono_lty TyOpPrec ty2 -ppr_mono_ty ctxt_prec (HsAppsTy tys) - = maybeParen ctxt_prec TyConPrec $ - hsep (map (ppr_app_ty TopPrec . unLoc) tys) +ppr_mono_ty _ctxt_prec (HsAppsTy tys) + = hsep (map (ppr_app_ty TopPrec . unLoc) tys) -ppr_mono_ty ctxt_prec (HsAppTy fun_ty arg_ty) - = maybeParen ctxt_prec TyConPrec $ - hsep [ppr_mono_lty FunPrec fun_ty, ppr_mono_lty TyConPrec arg_ty] +ppr_mono_ty _ctxt_prec (HsAppTy fun_ty arg_ty) + = hsep [ppr_mono_lty FunPrec fun_ty, ppr_mono_lty TyConPrec arg_ty] }}} Adding back the `maybeParen ctxt_prec TyConPrec` part in the `HsAppTy` case fixes the issue for me. However, I suspect you made this change for a reason, alanz - do you know what's going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 06:10:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 06:10:59 -0000 Subject: [GHC] #13200: Old links to snapshot releases in GHC user's guide Message-ID: <047.f7f0f101e09c8b8fdb8de7eba80b82aa@haskell.org> #13200: Old links to snapshot releases in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- Following links are out-of-date in GHC user's guide; secsion '2.4. GHC version numbering policy' [1]: * We may make snapshot releases of the current stable branch __available for download__ , * We may make snapshot releases of the HEAD __available for download__, Currently there are no snapshot releases? [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/intro.html #ghc-version-numbering-policy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 07:54:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 07:54:19 -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.332f703edd8945f02cb3ae2784ff805d@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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 alanz): * owner: => alanz Comment: I will take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 09:31:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 09:31: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.81b14eaa650f8ba3b344e219a6667dbd@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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 alanz): I think this is related to point 3 in the description of https://phabricator.haskell.org/D2752 Basically `HsParTy` appears everywhere it needs to in the `ParsedSource`, but it somehow disappears through the renamer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 09:38:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 09:38:22 -0000 Subject: [GHC] #13201: Type-level naturals aren't instantiate with GHCi debugger Message-ID: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> #13201: Type-level naturals aren't instantiate with GHCi debugger -------------------------------------+------------------------------------- Reporter: konn | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi debugger cannot use the information of specific value type-level natural number, even if it is explicitly specified. For example, consider the following code: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, StandaloneDeriving, TypeOperators #-} module Main where import GHC.TypeLits data Foo (n :: Nat) = Foo deriving instance KnownNat n => Show (Foo n) fooSucc :: Foo n -> Foo (n + 1) fooSucc Foo = Foo foos :: Foo n -> [Foo (n + 1)] foos f = loop 5 where loop 0 = [] loop n = fooSucc f : loop (n - 1) main :: IO () main = print $ foos (Foo :: Foo 5) }}} Loading it with GHCi Debugger, we cannot `show` the value of `f`, because GHCi debugger doesn't know the specific value of `n` (in`Foo n`), even though we specify it in `main`! {{{#!hs ghci> :l tmp.hs [1 of 1] Compiling Main ( tmp.hs, interpreted ) Ok, modules loaded: Main. ghci> :break foos Breakpoint 0 activated at tmp.hs:13:10-15 ghci> :set stop :list ghci> main Stopped in Main.foos, tmp.hs:13:10-15 _result :: [Foo (n + 1)] = _ loop :: (Num t, Eq t) => t -> [Foo (n + 1)] = _ 12 foos :: Foo n -> [Foo (n + 1)] 13 foos f = loop 5 14 where ghci> :step Stopped in Main.foos.loop, tmp.hs:16:14-37 _result :: [Foo (n + 1)] = _ f :: Foo n = _ n :: Integer = 5 15 loop 0 = [] 16 loop n = fooSucc f : loop (n - 1) 17 ghci> :t f f :: Foo n ghci> f :8:1: error: • No instance for (KnownNat n) arising from a use of ‘print’ • In a stmt of an interactive GHCi command: print it }}} Of course, we can inspect the internal representation via `:print` or `:force` command, but it is rather impractical when we cannot easily read its pretty form from its internal representation . I tested this with GHC 7.0.1 and 7.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 13:17:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 13:17:48 -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.45493e2254ee61ceee3f44d1ed72405d@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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 alanz): Tracing it through, the problem comes inside `runRnSplice`, where we end up (using `showAstData`) with `zonked_q_expr` passing {{{ ... ({ T13199.hs:9:16-28 } (HsAppTy ({ T13199.hs:9:16-18 } (HsAppTy ({ T13199.hs:9:16 } (HsTyVar (NotPromoted) ({ T13199.hs:9:16 }{Name: main:Bug.C{tc row}}))) ({ T13199.hs:9:18 } (HsTyVar (NotPromoted) ({ T13199.hs:9:18 }{Name: a{tv aqF}}))))) ({ T13199.hs:9:20-28 } (HsParTy ({ T13199.hs:9:21-27 } (HsAppTy ({ T13199.hs:9:21-25 } (HsTyVar (NotPromoted) ({ T13199.hs:9:21-25 }{Name: base:GHC.Base.Maybe{(w) tc 3Q}}))) ({ T13199.hs:9:27 } (HsTyVar (NotPromoted) ({ T13199.hs:9:27 }{Name: b{tv aqG}}))))))))) ... }}} to {{{#!hs ; result <- setStage (RunSplice mod_finalizers_ref) $ run_meta zonked_q_expr }}} giving {{{ ... ({ T13199.hs:(9,3)-(10,6) } (HsAppTy ({ T13199.hs:(9,3)-(10,6) } (HsAppTy ({ T13199.hs:(9,3)-(10,6) } (HsTyVar (NotPromoted) ({ } (Orig ({abstract:Module}) {OccName: C})))) ({ T13199.hs:(9,3)-(10,6) } (HsTyVar (NotPromoted) ({ T13199.hs:(9,3)-(10,6) } (Exact {Name: a_a3Ub{tv}})))))) ({ T13199.hs:(9,3)-(10,6) } (HsAppTy ({ T13199.hs:(9,3)-(10,6) } (HsTyVar (NotPromoted) ({ } (Orig ({abstract:Module}) {OccName: Maybe})))) ({ T13199.hs:(9,3)-(10,6) } (HsTyVar (NotPromoted) ({ T13199.hs:(9,3)-(10,6) } (Exact {Name: b_a3Uc{tv}})))))))) ... }}} So something happening via the `run_meta` process is discarding the `HsParTy`. And in this instance `run_meta` is {{{#!hs runMetaD :: LHsExpr Id -- Of type Q [Dec] -> TcM [LHsDecl RdrName] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 15:05:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 15:05:27 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.87fa7c080137556c545ca8fab2eb0c17@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): Firstly: I said "I just noticed that this means", i.e. this was a pure deduction, not an observation. Apart from that, I never meant to suggest making -I0 the default, and I think the two goals (deadlock detection and latency reduction) do align here. So between options a) status quo b) default -I0 c) something more clever that both does deadlock detection and uses, lets say.. 3% idle cpu time, I'd choose c) over a) over b). I am not sure how the budget would be enforced, but it sounds like a good idea, especially if that is easier to implement than the heuristics I mentioned above. Another thought: If there was an upper bound on the interval between full GCs (idle or not) you'd get reliable deadlock detection even with "forever threaddelay" cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 16:08:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 16:08:26 -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.d837f89696bce40afb8a0d5e7b2c02af@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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 RyanGlScott): Ah, so GHC will only print parentheses around types is an explicit `HsParTy` is used? In that case, I believe I know what the real culprit is. If you dig down deep enough to the code that `runMetaD` is running, you'll eventually come to [http://git.haskell.org/ghc.git/blob/de78ee6fb77e7505160ab23e6e1b4e66dc87f698:/compiler/hsSyn/Convert.hs#l257 the part] in `Convert` that coverts a Template Haskell `InstanceD` to a `ClsInstDecl`: {{{#!hs cvtDec (InstanceD o ctxt ty decs) = do { let doc = text "an instance declaration" ; (binds', sigs', fams', ats', adts') <- cvt_ci_decs doc decs ; unless (null fams') (failWith (mkBadDecMsg doc fams')) ; ctxt' <- cvtContext ctxt ; L loc ty' <- cvtType ty ; let inst_ty' = mkHsQualTy ctxt loc ctxt' $ L loc ty' ; returnJustL $ InstD $ ClsInstD $ ClsInstDecl { cid_poly_ty = mkLHsSigType inst_ty' , cid_binds = binds' , cid_sigs = Hs.mkClassOpSigs sigs' , cid_tyfam_insts = ats', cid_datafam_insts = adts' , cid_overlap_mode = fmap (L loc . overlap) o } } }}} In particular, if you trace the value of `ty'` when you run the program above, it'll give you `instance C a_a4m5 Maybe b_a4m6`. That's because the original Template Haskell AST for this is: {{{ λ> import Language.Haskell.TH λ> putStrLn $([d| instance C a (Maybe b) |] >>= stringE . show) [InstanceD Nothing [] (AppT (AppT (ConT Bug.C) (VarT a_6989586621679027494)) (AppT (ConT GHC.Base.Maybe) (VarT b_6989586621679027495))) []] }}} That is, there are no AST nodes to indicate parentheses. That's because when we originally quoted this declaration earlier, `repTy` (located [http://git.haskell.org/ghc.git/blob/de78ee6fb77e7505160ab23e6e1b4e66dc87f698:/compiler/deSugar/DsMeta.hs#l1035 here] in `DsMeta`) turns the `HsType` into a Template Haskell `Type`. And `repTy` has this as one of its cases: {{{#!hs repTy (HsParTy t) = repLTy t }}} `repTy` strips away all parentheses, and this is by design, according to [http://git.haskell.org/ghc.git/blob/de78ee6fb77e7505160ab23e6e1b4e66dc87f698:/libraries /template-haskell/Language/Haskell/TH/Syntax.hs#l1441 this note]: {{{#!hs --- * Quoted expressions such as --- --- > [| a * b + c |] :: Q Exp --- > [p| a : b : c |] :: Q Pat --- > [t| T + T |] :: Q Type --- --- will never contain 'UInfixE', 'UInfixP', 'UInfixT', 'InfixT', 'ParensE', --- 'ParensP', or 'ParensT' constructors. }}} So I believe the proper fix here is //not// to make `repTy` turn an `HsParTy` into a `ParensT`, but rather to change `cvtType` so that it inserts `HsParTy`s appropriately as it converts from a TH AST back to an `HsType`, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 16:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 16:32:38 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.f2f02ce9c6bb53ed1406dd86fb5512f6@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: | -------------------------------------+------------------------------------- Changes (by amindfv): * differential: Phab:D2816 => Phab:D2822 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 16:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 16:47:26 -0000 Subject: [GHC] #13202: Levity polymorphism panic in GHCi Message-ID: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> #13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With current `master`, {{{ $ ghci GHCi, version 8.1.20170126: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import GHC.Exts λ> :set -XTypeApplications -XMagicHash -XTypeInType λ> data TypeRep (a :: k) = TypeRep λ> let typeRepKind = undefined :: TypeRep (a :: k) -> TypeRep k λ> let typeRep = undefined :: TypeRep (a :: k) λ> let x = typeRepKind (typeRep @(Maybe Int#)) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170126 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:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1869:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 17:26:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 17:26:13 -0000 Subject: [GHC] #13193: Integer (gmp) performance regression? In-Reply-To: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> References: <049.413a0b17762ed375a5821293dec1ac28@haskell.org> Message-ID: <064.1bfabfe8061b6ca6be182c42963edc27@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 j.waldmann): > test with perf build of HEAD {{{ ghc-8.1.20170128 : 2.14 sec }}} so this is roughly the performance of 7.10, better than 8.0, but still not 7.8 or earlier. I also updated the data at http://www.imn.htwk-leipzig.de/~waldmann/etc/mob/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 19:02:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 19:02:57 -0000 Subject: [GHC] #13203: Implement Bits Natural clearBit Message-ID: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> #13203: Implement Bits Natural clearBit -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current Bits Natural implementation says: {{{TODO: setBit, clearBit, complementBit (needs more primitives)}}}. The default implementations of setBit and complementBit work fine, but clearBit relies on complement, and so fails. Even if it had to use a conditional complementBit on testBit, it would be better than nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 19:03:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 19:03:40 -0000 Subject: [GHC] #13203: Implement Bits Natural clearBit In-Reply-To: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> References: <044.036af31a947c4008bf1dfa61730885bd@haskell.org> Message-ID: <059.a641d2a727d7ecb136ca544444e25589@haskell.org> #13203: Implement Bits Natural clearBit -------------------------------------+------------------------------------- Reporter: dylex | Owner: 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: | -------------------------------------+------------------------------------- Changes (by dylex): * priority: normal => lowest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 20:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 20:08:12 -0000 Subject: [GHC] #13201: Type-level naturals aren't instantiate with GHCi debugger In-Reply-To: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> References: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> Message-ID: <058.5e140dea86d1d1479ed5a1965c4d90a9@haskell.org> #13201: Type-level naturals aren't instantiate 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Sadly, the GHCi debugger has no current maintainer. It is slowly rotting. Would you (for all values of "you") be able to step in and help? :) I can't even offer to advise, because I have no clue how the code works. But, if someone stood up to say that they would maintain it, we could perhaps hunt down the original implementor and get more info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 22:44:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 22:44:13 -0000 Subject: [GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char In-Reply-To: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> References: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> Message-ID: <065.adb260a74ae3682ae2ccf13e625917a2@haskell.org> #13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3033 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bc42e2b03a87e3f6c0d24584382f281c6580801b/ghc" bc42e2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc42e2b03a87e3f6c0d24584382f281c6580801b" Convert pprTrace in isPredTy to a WARN Summary: There was a `pprTrace` in `isPredTy` that could fire under certain scenarios, causing normal GHC users to see debugging output. This turns it into a less chatty `WARN`, and expounds on the comment below it to add the scenario in #13187 which triggered the `pprTrace`. Reviewers: goldfire, austin, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3033 GHC Trac Issues: #13187 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 22:44:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 22:44:54 -0000 Subject: [GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char In-Reply-To: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> References: <050.0fe05f04948380b921d10ecbdf9a8860@haskell.org> Message-ID: <065.bd145ea08796ae078664cfd643adf73b@haskell.org> #13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3033 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 28 22:48:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jan 2017 22:48:31 -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.130193a5b70704124c1e81a68bbf851b@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 scpmw): Well, turns out the "elegant" way does actually not work: The intermediate source notes get floated up, and we still end up with `O(n^3)` complexity at intermediate `wrapTicks` stages. Plus the top-level source note had actually been in the list of floats anyway - just at first position, which gets applied by `foldr` last. So we were applying all sorts of fine- grained ticks on `n` expressions just to get rid of all of them in the end. phab:D3037 fixes this behaviour of `wrapTicks`. It's rather straightforward, really: Instead of using a `foldr` to apply ticks from the right, we start at the left and drop ticks immediately when we see that they are redundant. This should be `O(n)` for list literals now. Sorry for that, rather silly mistake :/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 00:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 00:42:39 -0000 Subject: [GHC] #13204: Core Lint error running testsuite with DEBUG way Message-ID: <047.381ba5a00f4e3199e228a3db6ee351e7@haskell.org> #13204: Core Lint error running testsuite with DEBUG way -------------------------------------+------------------------------------- Reporter: dobenour | 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: -------------------------------------+------------------------------------- I was testing Phab:D2996 for benchmarking purposes, and I noticed that some tests failed in the `ghci` way. I re-ran them with the `debug` way, and got a Core Lint failure: {{{ [1 of 1] Compiling Main ( StrictPats.hs, StrictPats.o ) *** Core Lint errors : in result of Simplifier *** : warning: [RHS of q_s50e :: Addr#] Recursive or top-level binder has strict demand info: q_s50e Binder's demand info: *** Offending Program *** $dIP_s50d :: CallStack [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 300 0}] $dIP_s50d = pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 27#) (I# 14#) (I# 27#) (I# 23#)) emptyCallStack ds_d4Z4 :: forall a. a [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] ds_d4Z4 = \ (@ a_a4SJ) -> undefined @ 'LiftedRep @ a ($dIP_s50d `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) a :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] a = True b :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 330 10}] b = case \ (@ a_a4Hg) -> undefined @ 'LiftedRep @ a ((pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 32#) (I# 14#) (I# 32#) (I# 23#)) emptyCallStack) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) of { __DEFAULT -> True } c :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] c = True d :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 320 0}] d = case undefined @ 'LiftedRep @ Int ((pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 40#) (I# 17#) (I# 40#) (I# 26#)) emptyCallStack) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) of wild_00 { } e :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] e = True f :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 320 0}] f = case undefined @ 'IntRep @ Int# ((pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 48#) (I# 14#) (I# 48#) (I# 23#)) emptyCallStack) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) of wild_00 { } g :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] g = True h :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] h = True i :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 320 0}] i = case undefined @ ('TupleRep '['IntRep]) @ (# Int# #) ((pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 60#) (I# 20#) (I# 60#) (I# 29#)) emptyCallStack) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) of wild_00 { } j :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 100 0}] j = case irrefutPatError @ 'LiftedRep @ () "StrictPats.hs:64:9-21|True"# of wild_00 { } k :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] k = True l :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] l = True m :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 90 0}] m = case irrefutPatError @ 'LiftedRep @ () "StrictPats.hs:76:9-16|3#"# of wild_00 { } n :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 320 0}] n = case undefined @ ('TupleRep '['LiftedRep]) @ (# () #) ((pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 80#) (I# 14#) (I# 80#) (I# 23#)) emptyCallStack) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) of wild_00 { } o :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] o = True p :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] p = True q_s50e :: Addr# [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 110 0}] q_s50e = "StrictPats.hs:92:9-54|pattern binding"# q :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] q = patError @ 'LiftedRep @ Bool q_s50e r :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] r = True s :: Bool [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 340 10}] s = case \ (@ a_a3DN) -> let { ds_d4Xb :: (a) [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 320 0}] ds_d4Xb = case undefined @ ('TupleRep '['LiftedRep]) @ (# a #) ((pushCallStack (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "undefined"#), SrcLoc (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Main"#)) (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "StrictPats.hs"#)) (I# 100#) (I# 20#) (I# 100#) (I# 29#)) emptyCallStack) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) of wild_00 { } } in ds_d4Xb of { __DEFAULT -> True } $trModule_s50h :: Addr# [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s50h = "main"# $trModule_s50g :: TrName [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s50g = TrNameS $trModule_s50h $trModule_s50j :: Addr# [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s50j = "Main"# $trModule_s50i :: TrName [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s50i = TrNameS $trModule_s50j $trModule :: Module [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module $trModule_s50g $trModule_s50i bad :: forall a. a -> IO () [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 400 60}] bad = \ (@ a_a4T7) (x_a3ed :: a) -> bindIO @ (Either SomeException a) @ () ($ @ 'LiftedRep @ (IO a) @ (IO (Either SomeException a)) (try @ SomeException @ a $fExceptionSomeException) (evaluate @ a x_a3ed)) (\ (r_a3qv :: Either SomeException a) -> case r_a3qv of { Left ds_d4Zg -> putStrLn (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Exception thrown as expected."#)); Right ds_d4Zh -> putStrLn (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Exception not thrown when expected."#)) }) ok :: forall a. a -> IO () [LclIdX, Arity=2, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 160 0}] ok = \ (@ a_a4U0) (x_a37y :: a) -> (\ (eta_B1 :: State# RealWorld) -> ((thenIO @ a @ () (evaluate @ a x_a37y) (putStrLn (build @ Char (\ (@ b_a503) -> unpackFoldrCString# @ b "Evaluation successful."#)))) `cast` (N:IO[0] <()>_R :: (IO () :: *) ~R# ((State# RealWorld -> (# State# RealWorld, () #)) :: *))) eta_B1) `cast` (Sym (N:IO[0] <()>_R) :: ((State# RealWorld -> (# State# RealWorld, () #)) :: *) ~R# (IO () :: *)) main_s5ge :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5ge = ok @ Bool a main_s5gg :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gg = bad @ Bool b main_s5gi :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gi = ok @ Bool c main_s5gk :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gk = bad @ Bool d main_s5gm :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gm = ok @ Bool e main_s5go :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5go = bad @ Bool f main_s5gq :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gq = ok @ Bool g main_s5gs :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gs = ok @ Bool h main_s5gu :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gu = bad @ Bool i main_s5gw :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gw = bad @ Bool j main_s5gy :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gy = ok @ Bool k main_s5gA :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gA = ok @ Bool l main_s5gC :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gC = bad @ Bool m main_s5gE :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gE = bad @ Bool n main_s5gG :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gG = ok @ Bool o main_s5gI :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gI = ok @ Bool p main_s5gK :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gK = bad @ Bool q main_s5gM :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main_s5gM = ok @ Bool r main_s5gN :: IO () [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] main_s5gN = bad @ Bool s main_s5gL :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gL = thenIO @ () @ () main_s5gM main_s5gN main_s5gJ :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gJ = thenIO @ () @ () main_s5gK main_s5gL main_s5gH :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gH = thenIO @ () @ () main_s5gI main_s5gJ main_s5gF :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gF = thenIO @ () @ () main_s5gG main_s5gH main_s5gD :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gD = thenIO @ () @ () main_s5gE main_s5gF main_s5gB :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gB = thenIO @ () @ () main_s5gC main_s5gD main_s5gz :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gz = thenIO @ () @ () main_s5gA main_s5gB main_s5gx :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gx = thenIO @ () @ () main_s5gy main_s5gz main_s5gv :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gv = thenIO @ () @ () main_s5gw main_s5gx main_s5gt :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gt = thenIO @ () @ () main_s5gu main_s5gv main_s5gr :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gr = thenIO @ () @ () main_s5gs main_s5gt main_s5gp :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gp = thenIO @ () @ () main_s5gq main_s5gr main_s5gn :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gn = thenIO @ () @ () main_s5go main_s5gp main_s5gl :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gl = thenIO @ () @ () main_s5gm main_s5gn main_s5gj :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gj = thenIO @ () @ () main_s5gk main_s5gl main_s5gh :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gh = thenIO @ () @ () main_s5gi main_s5gj main_s5gf :: IO () [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main_s5gf = thenIO @ () @ () main_s5gg main_s5gh main :: IO () [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] main = thenIO @ () @ () main_s5ge main_s5gf main :: IO () [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] main = runMainIO @ () main *** End of Offense *** : error: Compilation had errors *** unexpected failure for StrictPats(debug) }}} I could not see how my patch to the interpreter would cause a Core Lint failure, so I am reporting this as a bug. CCing simonpj because this is either a bug in the typechecker, the desugarer, or a core-to-core optimization pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 00:44:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 00:44:08 -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.731107dd9d05136ce930529fe737b417@haskell.org> #13204: Core Lint error running testsuite with DEBUG way -------------------------------------+------------------------------------- Reporter: dobenour | 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 dobenour): The failure does not appear in the `normal` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 00:48:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 00:48:07 -0000 Subject: [GHC] #13205: Run `validate --slow` during CI at least sometimes. Message-ID: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> #13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | 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 really should run `validate --slow` at times. It would catch #13204. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 01:15:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 01:15:17 -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.abb1bb3c5404c2e1d7ff36bf1a955dcf@haskell.org> #13204: Core Lint error running testsuite with DEBUG way -------------------------------------+------------------------------------- Reporter: dobenour | 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): This is likely fallout from the top-level strings patch (d49b2bb21691892ca6ac8f2403e31f2a5e53feb3). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 05:14:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 05:14:00 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.8483055e3422b6eeec05651060b4c97a@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: #12980 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): An exhaustive search through `ghc-prim` and `base` found 34 (!) classes that can be generalized this way: {{{ Eq, Ord, Functor, Applicative, Monad, MonadFail, MonadFix, MonadIO, Bifoldable, Bifunctor, HasResolution, Foldable, Eq1, Ord1, Eq2, Ord2, IsString, TestCoercion, TestEquality, Storable, IsList, Num, Real, Fractional, Generic, Generic1, GHCiSandboxIO, BufferedIO, RawIO, IsLabel, PrintfType, HPrintfType, PrintfArg, IsChar }}} Some are surely more useful to generalize than others. But wow! More classes morally could be included in this list but for two limiting factors: - Many classes use lists somewhere. (For example, `Show`.) However, we could define a family of list types, one for each representation (which would box unboxed tuples), and then use a type family to select the appropriate list type, allowing generalizations of classes that use lists. - Several classes (e.g., `Integral`) use tuples, preventing generalization. But we could just use unboxed tuples and away we go. Another annoyance was that `Applicative` can be generalized to make its parameter `f :: Type -> TYPE r`, but not `f :: TYPE r1 -> TYPE r2`. The latter is impossible because the class definition mentions `f (a -> b)`, and functions are always lifted. It would be lovely, though, to ponder the possibility of `class Applicative (f :: forall (r1 :: RuntimeRep). TYPE r1 -> TYPE r2)`, where `Applicative` would then have a higher-rank kind. And, we could generalize `IO` (it's implemented using an unboxed tuple, after all) and then `IO` could be made an instance of this new `Applicative`. `Monad` would soon follow, and you'd then be able to return unboxed values in `do`-notation. A final note: In testing all this, I had to add `default` signatures imposing a `r ~ LiftedRep` constraint whenever a generalized class had a default implementation, because the default implementation would work only at kind `Type`. This works, but it's disappointing that there can be no defaults at representations other than `LiftedRep`. However, I've realized we ''can''. Instead of `r ~ LiftedRep` in the `default` signature, impose a `Typeable r` constraint. Then we can do a runtime type test to figure out the representation and to squash the levity polymorphism. (This actually works.) A sufficiently smart compiler would be able to optimize away the runtime type test in any non-levity-polymorphic class instance. And we're just left with happiness and a wicked powerful type system. My (rushed, somewhat shoddy) work on this is [https://github.com/goldfirere/ghc/tree/lev-poly-base here]. I don't expect that to ever be merged -- I just was exploring the possibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 07:04:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 07:04:12 -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.690f41caea532073d20c5731d794e521@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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: ekmett (added) * status: new => patch * differential: => Phab:D3038 * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 07:06:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 07:06:49 -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.263c27537fb904aa6f33b46d5a20f61f@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 dfeuer): We still need a more reliable test case. I managed to make a variation of this one fail moderately reliably using lots more threads, but I have an idea for another approach that's probably cheaper and more reliable; I'll try to get to that shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 14:36:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 14:36:15 -0000 Subject: [GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility In-Reply-To: <045.0008d7bf15a6c184529405e4260be834@haskell.org> References: <045.0008d7bf15a6c184529405e4260be834@haskell.org> Message-ID: <060.2f0534be2c06b341b3770dcaa0c3b72a@haskell.org> #10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins07 Blocked By: | Blocking: 10294 Related Tickets: | Differential Rev(s): Phab:D950 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): This and other plugin tests are failing on Windows and I can't really figure out why. It Seems like a `cabal` bug. {{{ Tamar at CI MINGW64 /c/TeamCity/buildAgent/work/28754042a1be6052/testsuite/tests/plugins/plugins07.run /rule-defining-plugin $ make -C . package.plugins07 TOP=C:/TeamCity/buildAgent/work/28754042a1be6052/testsuite/ make: Entering directory '/c/TeamCity/buildAgent/work/28754042a1be6052/testsuite/tests/plugins/plugins07.run /rule-defining-plugin' make -s --no-print-directory clean.plugins07 mkdir pkg.plugins07 "/c/TeamCity/buildAgent/work/28754042a1be6052/inplace/bin/ghc-stage2.exe" -outputdir pkg.plugins07 --make -v0 -o pkg.plugins07/setup Setup.hs "/c/TeamCity/buildAgent/work/28754042a1be6052/inplace/bin/ghc-pkg.exe" init pkg.plugins07/local.package.conf pkg.plugins07/setup configure --distdir pkg.plugins07/dist -v0 --enable- library-vanilla --disable-shared --prefix="/c/TeamCity/buildAgent/work/28754042a1be6052/testsuite/tests/plugins/plugins07.run /rule-defining-plugin/pkg.plugins07/install" --with- compiler="/c/TeamCity/buildAgent/work/28754042a1be6052/inplace/bin/ghc- stage2.exe" --with-hc- pkg="/c/TeamCity/buildAgent/work/28754042a1be6052/inplace/bin/ghc-pkg.exe" --package-db=pkg.plugins07/local.package.conf pkg.plugins07/setup build --distdir pkg.plugins07/dist -v0 pkg.plugins07/setup install --distdir pkg.plugins07/dist -v3 /bin/sh: setup: command not found make: *** [Makefile:18: package.plugins07] Error 127 make: Leaving directory '/c/TeamCity/buildAgent/work/28754042a1be6052/testsuite/tests/plugins/plugins07.run /rule-defining-plugin' }}} My guess is that `cabal` is expecting `setup.exe` to be in the same folder as the `.cabal` file. Which these tests don't do. If this is the case, how can they be working on linux? the install partially works until dies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 16:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 16:58:30 -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.9e775f311d3fed10c5a8a341eb0d3c1f@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): Replying to [comment:53 rwbarton]: > Another suggestion is to add to the repo a big patch file that we apply to the untarred GMP 5.0.4 source to turn it into the GMP 6.1.2 source. (We apply some other patches after unpacking already.) I was unable to create such a patch smaller than 1MB compressed, even by importing the unpacked tarballs into git and creating a patch with `git format-patch -M -B -C -C -D`. So this doesn't seem like a promising approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 29 22:23:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jan 2017 22:23:38 -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.4326bd99f87fc549b7279e087e9dc5b7@haskell.org> #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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): Phab:D3043 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D3043 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 01:21:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 01:21:26 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation Message-ID: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | 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: -------------------------------------+------------------------------------- The Generic instance shown as automatically derived for the Tree type should read {{{ instance Generic (Tree a) where type Rep (Tree a) = D1 ('MetaData "Tree" "Main" "package-name" 'False) (C1 ('MetaCons "Leaf" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a)) :+: C1 ('MetaCons "Leaf" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Tree a)) :*: S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Tree a))))) from (Leaf f) = M1 (L1 (M1 (M1 (K1 f)))) from (Node f g) = M1 (R1 (M1 ((M1 (K1 f)) :*: (M1 (K1 g))))) to (M1 (L1 (M1 (M1 (K1 f))))) = Leaf f to (M1 (R1 (M1 ((M1 (K1 f)) :*: (M1 (K1 g)))))) = Node f g }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 01:26:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 01:26:14 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.de704787532d4f8c318150bba69eb9d7@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): I mean {{{ instance Generic (Tree a) where type Rep (Tree a) = D1 ('MetaData "Tree" "Main" "package-name" 'False) (C1 ('MetaCons "Leaf" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a)) :+: C1 ('MetaCons "Leaf" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Tree a)) :*: S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Tree a)))) from (Leaf f) = M1 (L1 (M1 (M1 (K1 f)))) from (Node f g) = M1 (R1 (M1 ((M1 (K1 f)) :*: (M1 (K1 g))))) to (M1 (L1 (M1 (M1 (K1 f))))) = Leaf f to (M1 (R1 (M1 ((M1 (K1 f)) :*: (M1 (K1 g)))))) = Node f g }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 01:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 01:29:26 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.b6140c46001953991e3bd8a90f5b6667@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics Comment: Forgive me for being slow, but which specific lines in the current `GHC.Generics` source code are wrong? And what in particular do you wish to change? It's hard to discern from all the autogenerated noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 01:33:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 01:33:30 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.f9fbdad13c870f3b96b42d55b9054885@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): If you go to https://hackage.haskell.org/package/base-4.9.1.0/docs/GHC- Generics.html it is the second block of code. It is near the top of http://git.haskell.org/ghc.git/blob_plain/HEAD:/libraries/base/GHC/Generics.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 01:37:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 01:37:35 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.1d826b4b861f3130c0ccba0613f422aa@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): dsf, I presume you're referring to this? http://git.haskell.org/ghc.git/blob/4441f90738e27ea7ba368723f27d19c03093aa66:/libraries/base/GHC/Generics.hs#l75 Granted, my eyes aren't as sharp as they used to be, but from a glance, that `Rep (Tree a)` instances appears to be the same as yours. So can you point to the specific part that you claim is incorrect? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 04:04:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 04:04:22 -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.9a788bc786361c9e259c220fcc219782@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * owner: hvr => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 04:35:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 04:35: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.6cc810beff5dfb7a3cad7b89ef713b73@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3044 Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * differential: => Phab:3044 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 04:36:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 04:36:05 -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.8449e9e91358ccb7b57d5eb404cab1b5@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * differential: Phab:3044 => Phab:D3044 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 05:30:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 05:30:09 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.4691143c531f71250f24d7b9abf59df2@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): It turns out its just this: {{{ --- old 2017-01-29 21:28:30.598988361 -0800 +++ new 2017-01-29 21:28:46.650987621 -0800 @@ -2,7 +2,7 @@ type Rep (Tree a) = D1 ('MetaData "Tree" "Main" "package-name" 'False) (C1 ('MetaCons "Leaf" 'PrefixI 'False) - (S1 '(MetaSel 'Nothing + (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 05:48:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 05:48:02 -0000 Subject: [GHC] #13207: Performance regressions from removing LNE analysis Message-ID: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> #13207: Performance regressions from removing LNE analysis -------------------------------------+------------------------------------- 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: 12988 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `CoreToStg`'s LNE analysis has been superseded by the occurrence analyzer's join-point analysis. However, there are a few cases where the occurrence analyzer doesn't find a join point where the old analysis would've found an LNE. Known causes include: 1. The LNE analysis was untyped, which (very) occasionally allows an LNE where a join point would've fallen afoul of the polymorphism rule (see Note [The polymorphism rule of join points] in `CoreSyn.hs`). 2. Sometimes a rewrite rule prevents a binding from being christened a join point; such a binding would've been found by the LNE analysis (which runs after Core Tidy has removed rules from local binders). The biggest loss in NoFib is `spectral/cryptarithm2`, which saw a 0.3% increase in allocations because a rule prevented detection of a join point. Specifically, there's a `go` that gets SpecConstr'd as an `$sgo`. All the calls to `$sgo` happen to be tail calls, but some calls to `go` aren't, so it's only the rule that keeps `$sgo` from becoming a join point. In summary (adapted from the `cryptarithm2` situation): {{{ letrec $sgo = \x y z -> ... go {- non-tail call -} ... {-# RULE "SPEC go" forall x y z. go ((x,y):z) = $sgo x y z #-} go = \xs -> ... go ... in ... go ... $sgo a b c {- tail call -} ... }}} The only thing keeping `$sgo` from becoming a join point is the rule. Possible solutions: 1. Run the occurrence analyzer after Core Tidy. Seems like the solution needing the least code. Problems: * Core Tidy turns top-level binders into `GlobalId`s. Would need to adapt the occurrence analyzer. * Would also need to run the simplifier, or at least `simpleOptPgm`, after Core Tidy, so one of those would also have to adapt. * Only covers case 2. 2. Write a new pass that just throws out all the rules from the local binders in the module, then run it (and then the simplifier) at the end of the Core-to-Core pipeline, just before Core Tidy. (Local rules don't appear in ifaces anyway.) * Needs a whole new traversal, albeit a very simple one. Though it's possible that dropping the rules would lead to other optimizations (`$sgo` would end up pre-inlined in the above example), so it might be helpful anyway. * Also only covers case 2. 3. Write the LNE analysis as an STG-to-STG pass. Only idea that covers both cases. * Needs even more code, and duplicative of the occurrence analyzer. 4. Loosen the join-point invariants somehow. For example, if we could flag a rule as applying only to tail calls, that rule could contain a jump in its RHS even though its LHS isn't a jump. * But this is already problematic in the above example—we also can't make `$sgo` a join point so long as it's mutually recursive with `go`, which it still is so long as the rule is there. In other words, even if the rule doesn't directly keep `$sgo` from being a join point, it's still the only thing keeping it from breaking free of `go`'s recursive group, which it must do to become a join point. * So it doesn't cover case 2 very well and it doesn't cover case 1 at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 05:48:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 05:48:49 -0000 Subject: [GHC] #13207: Performance regressions from removing LNE analysis In-Reply-To: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> References: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> Message-ID: <064.a36d26d3bd7e80bb5f2d3728bd7da54a@haskell.org> #13207: Performance regressions from removing LNE analysis -------------------------------------+------------------------------------- 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: 12988 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukemaurer): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 05:58:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 05:58:25 -0000 Subject: [GHC] #13207: Performance regressions from removing LNE analysis In-Reply-To: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> References: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> Message-ID: <064.7164626e4620c376fe1508fed534ce69@haskell.org> #13207: Performance regressions from removing LNE analysis -------------------------------------+------------------------------------- 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: 12988 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lukemaurer: @@ -32,6 +32,5 @@ - 1. Run the occurrence analyzer after Core Tidy. Seems like the solution - needing the least code. Problems: - * Core Tidy turns top-level binders into `GlobalId`s. Would need to - adapt the occurrence analyzer. - * Would also need to run the simplifier, or at least `simpleOptPgm`, - after Core Tidy, so one of those would also have to adapt. + 1. Run the occurrence analyzer and the simplifier (or `simpleOptPgm`) + after Tidy Core. Seems like the solution needing the least code. Problems: + * Tidy Core turns top-level binders into `GlobalId`s. Would need to + adapt the occurrence analyzer and the simplifier, or not do that in Core + Tidy. New description: `CoreToStg`'s LNE analysis has been superseded by the occurrence analyzer's join-point analysis. However, there are a few cases where the occurrence analyzer doesn't find a join point where the old analysis would've found an LNE. Known causes include: 1. The LNE analysis was untyped, which (very) occasionally allows an LNE where a join point would've fallen afoul of the polymorphism rule (see Note [The polymorphism rule of join points] in `CoreSyn.hs`). 2. Sometimes a rewrite rule prevents a binding from being christened a join point; such a binding would've been found by the LNE analysis (which runs after Core Tidy has removed rules from local binders). The biggest loss in NoFib is `spectral/cryptarithm2`, which saw a 0.3% increase in allocations because a rule prevented detection of a join point. Specifically, there's a `go` that gets SpecConstr'd as an `$sgo`. All the calls to `$sgo` happen to be tail calls, but some calls to `go` aren't, so it's only the rule that keeps `$sgo` from becoming a join point. In summary (adapted from the `cryptarithm2` situation): {{{ letrec $sgo = \x y z -> ... go {- non-tail call -} ... {-# RULE "SPEC go" forall x y z. go ((x,y):z) = $sgo x y z #-} go = \xs -> ... go ... in ... go ... $sgo a b c {- tail call -} ... }}} The only thing keeping `$sgo` from becoming a join point is the rule. Possible solutions: 1. Run the occurrence analyzer and the simplifier (or `simpleOptPgm`) after Tidy Core. Seems like the solution needing the least code. Problems: * Tidy Core turns top-level binders into `GlobalId`s. Would need to adapt the occurrence analyzer and the simplifier, or not do that in Core Tidy. * Only covers case 2. 2. Write a new pass that just throws out all the rules from the local binders in the module, then run it (and then the simplifier) at the end of the Core-to-Core pipeline, just before Core Tidy. (Local rules don't appear in ifaces anyway.) * Needs a whole new traversal, albeit a very simple one. Though it's possible that dropping the rules would lead to other optimizations (`$sgo` would end up pre-inlined in the above example), so it might be helpful anyway. * Also only covers case 2. 3. Write the LNE analysis as an STG-to-STG pass. Only idea that covers both cases. * Needs even more code, and duplicative of the occurrence analyzer. 4. Loosen the join-point invariants somehow. For example, if we could flag a rule as applying only to tail calls, that rule could contain a jump in its RHS even though its LHS isn't a jump. * But this is already problematic in the above example—we also can't make `$sgo` a join point so long as it's mutually recursive with `go`, which it still is so long as the rule is there. In other words, even if the rule doesn't directly keep `$sgo` from being a join point, it's still the only thing keeping it from breaking free of `go`'s recursive group, which it must do to become a join point. * So it doesn't cover case 2 very well and it doesn't cover case 1 at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 06:00:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 06:00:05 -0000 Subject: [GHC] #13207: Performance regressions from removing LNE analysis In-Reply-To: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> References: <049.70a252d5c110f95144db07dc8a43b5bd@haskell.org> Message-ID: <064.db950f67aa7e79868a09c35101833367@haskell.org> #13207: Performance regressions from removing LNE analysis -------------------------------------+------------------------------------- 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: 12988 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lukemaurer: @@ -35,2 +35,2 @@ - adapt the occurrence analyzer and the simplifier, or not do that in Core - Tidy. + stop doing that there or adapt the occurrence analyzer and the simplifier + (or `simpleOptPgm`). New description: `CoreToStg`'s LNE analysis has been superseded by the occurrence analyzer's join-point analysis. However, there are a few cases where the occurrence analyzer doesn't find a join point where the old analysis would've found an LNE. Known causes include: 1. The LNE analysis was untyped, which (very) occasionally allows an LNE where a join point would've fallen afoul of the polymorphism rule (see Note [The polymorphism rule of join points] in `CoreSyn.hs`). 2. Sometimes a rewrite rule prevents a binding from being christened a join point; such a binding would've been found by the LNE analysis (which runs after Core Tidy has removed rules from local binders). The biggest loss in NoFib is `spectral/cryptarithm2`, which saw a 0.3% increase in allocations because a rule prevented detection of a join point. Specifically, there's a `go` that gets SpecConstr'd as an `$sgo`. All the calls to `$sgo` happen to be tail calls, but some calls to `go` aren't, so it's only the rule that keeps `$sgo` from becoming a join point. In summary (adapted from the `cryptarithm2` situation): {{{ letrec $sgo = \x y z -> ... go {- non-tail call -} ... {-# RULE "SPEC go" forall x y z. go ((x,y):z) = $sgo x y z #-} go = \xs -> ... go ... in ... go ... $sgo a b c {- tail call -} ... }}} The only thing keeping `$sgo` from becoming a join point is the rule. Possible solutions: 1. Run the occurrence analyzer and the simplifier (or `simpleOptPgm`) after Tidy Core. Seems like the solution needing the least code. Problems: * Tidy Core turns top-level binders into `GlobalId`s. Would need to stop doing that there or adapt the occurrence analyzer and the simplifier (or `simpleOptPgm`). * Only covers case 2. 2. Write a new pass that just throws out all the rules from the local binders in the module, then run it (and then the simplifier) at the end of the Core-to-Core pipeline, just before Core Tidy. (Local rules don't appear in ifaces anyway.) * Needs a whole new traversal, albeit a very simple one. Though it's possible that dropping the rules would lead to other optimizations (`$sgo` would end up pre-inlined in the above example), so it might be helpful anyway. * Also only covers case 2. 3. Write the LNE analysis as an STG-to-STG pass. Only idea that covers both cases. * Needs even more code, and duplicative of the occurrence analyzer. 4. Loosen the join-point invariants somehow. For example, if we could flag a rule as applying only to tail calls, that rule could contain a jump in its RHS even though its LHS isn't a jump. * But this is already problematic in the above example—we also can't make `$sgo` a join point so long as it's mutually recursive with `go`, which it still is so long as the rule is there. In other words, even if the rule doesn't directly keep `$sgo` from being a join point, it's still the only thing keeping it from breaking free of `go`'s recursive group, which it must do to become a join point. * So it doesn't cover case 2 very well and it doesn't cover case 1 at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 06:32:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 06:32:33 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm Message-ID: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | 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: -------------------------------------+------------------------------------- As of #12988, having `simpleOptPgm` leave β-redexes lying around is painful because it requires a special loophole in Core Lint to allow a jump inside a β-redex. We'd rather use a two-phase approach, mirroring the simplifier's `preInlineUnconditionally` and `postInlineUnconditionally`, so we can aggressively eliminate β-redexes without fear of exponential blowup. Consider: {{{ joinrec j1 x = e1 in join j2 x y = jump j1 e2 in jump j2 e3 e4 }}} Since `j2` is only used once, it gets inlined. But `simpleOptPgm` only performs inlining //after// a binding is simplified, so we end up here: {{{ joinrec j1 x = e1' in (\x y -> jump j1 e2') e3' e4' }}} Since `e2'` was already simplified, performing the β-reduction here risks exponential blowup for the same reason it can happen in the simplifier (see the Secrets paper; `perf/compiler/T783` is a live example, increasing in allocs by over 80% if we re-simplify here). We //could// just `let`-bind `e3'` and `e4'` (carefully avoiding capturing free occurrences of `x` in `e4'`), but not if one them is actually a type argument. Well, okay, we //could// introduce a type `let`, but doing that here means the desugarer can now return a type `let` and we're not prepared for that. (Specifically, under certain circumstances, the simplifier never runs in between the desugarer and Float Out, and the latter breaks in the presence of type `let`.) So for the moment, we leave the β-redex there, but this needs a special rule just for β-redexes because normally you can't have a jump under a lambda (or an application, for that matter). In the long term, we'd prefer to take the simplifier's approach instead: If we want to inline something because it only occurs once (even though it may be big), we add it to the substitution //before// simplifying it so that we only simplify it once. This means the substitution has to carry lexical closures around, though, just like the simplifier does (see `SimplSR`'s `ContEx` disjunct), so it's not trivial. 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. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 11:23:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 11:23:13 -0000 Subject: [GHC] #13209: ghc panic with optimization. Message-ID: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHC rejects | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc eqFn && ./eqFn Works fine and the program runs fine too, but a bit slow. Adding optimization (-O) makes ghc panic (even after setting a bigger 'tick' factor): ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for i386-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone f_XOO To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 700804 My program eqFn.hs: {{{ {-# LANGUAGE FlexibleInstances #-} instance Eq a => Eq (Bool -> a) where f == g = f True == g True && f False == g False nand a b = not (a && b) xor a b = nand (nand a c) (nand b c) where c=nand a b halfAdder a b = (xor a b, a && b) -- (sum, cOut) fullAdder cIn a b = let (s, c') = halfAdder a b (sum, c'') = halfAdder cIn s in (sum, c' || c'') adder2 cIn a0 b0 a1 b1 = let (o0, cTmp) = fullAdder cIn a0 b0 (o1, cOut) = fullAdder cTmp a1 b1 in (o0, o1, cOut) adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 = let (o0, o1, cTmp) = adder2 cIn a0 b0 a1 b1 (o2, o3, cOut) = adder2 cTmp a2 b2 a3 b3 in (o0, o1, o2, o3, cOut) adder8 cIn a0 b0 a1 b1 a2 b2 a3 b3 a4 b4 a5 b5 a6 b6 a7 b7 = let (o0, o1, o2, o3, cTmp) = adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 (o4, o5, o6, o7, cOut) = adder4 cTmp a4 b4 a5 b5 a6 b6 a7 b7 in (o0, o1, o2, o3, o4, o5, o6, o7, cOut) main = print (adder8 == adder8) }}} Btw, it works if I replace adder8 with adder4 in the last line. I think this is a bug because, if the problem is too complicated for the optimizer it should just skip that part instead of failing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 11:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 11:24:14 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.d3b7b292310a515b399817f792ef1e6b@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by 1chb): * Attachment "eqFn.hs" added. Source code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 11:32:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 11:32:02 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.1fa2e4998d25a6dd629ea2e4bd23c9c9@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by 1chb: @@ -1,1 +1,6 @@ - ghc eqFn && ./eqFn + {{{ + > ghc eqFn && ./eqFn + [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) + Linking eqFn ... + True + }}} @@ -8,1 +13,2 @@ - ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn + {{{ + > ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn @@ -18,0 +24,1 @@ + }}} New description: {{{ > ghc eqFn && ./eqFn [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) Linking eqFn ... True }}} Works fine and the program runs fine too, but a bit slow. Adding optimization (-O) makes ghc panic (even after setting a bigger 'tick' factor): {{{ > ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for i386-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone f_XOO To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 700804 }}} My program eqFn.hs: {{{ {-# LANGUAGE FlexibleInstances #-} instance Eq a => Eq (Bool -> a) where f == g = f True == g True && f False == g False nand a b = not (a && b) xor a b = nand (nand a c) (nand b c) where c=nand a b halfAdder a b = (xor a b, a && b) -- (sum, cOut) fullAdder cIn a b = let (s, c') = halfAdder a b (sum, c'') = halfAdder cIn s in (sum, c' || c'') adder2 cIn a0 b0 a1 b1 = let (o0, cTmp) = fullAdder cIn a0 b0 (o1, cOut) = fullAdder cTmp a1 b1 in (o0, o1, cOut) adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 = let (o0, o1, cTmp) = adder2 cIn a0 b0 a1 b1 (o2, o3, cOut) = adder2 cTmp a2 b2 a3 b3 in (o0, o1, o2, o3, cOut) adder8 cIn a0 b0 a1 b1 a2 b2 a3 b3 a4 b4 a5 b5 a6 b6 a7 b7 = let (o0, o1, o2, o3, cTmp) = adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 (o4, o5, o6, o7, cOut) = adder4 cTmp a4 b4 a5 b5 a6 b6 a7 b7 in (o0, o1, o2, o3, o4, o5, o6, o7, cOut) main = print (adder8 == adder8) }}} Btw, it works if I replace adder8 with adder4 in the last line. I think this is a bug because, if the problem is too complicated for the optimizer it should just skip that part instead of failing. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 11:37:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 11:37:21 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.5bab0288a91c0bd07e074803179192d6@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => wontfix @@ -1,6 +1,1 @@ - {{{ - > ghc eqFn && ./eqFn - [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) - Linking eqFn ... - True - }}} + ghc eqFn && ./eqFn @@ -13,2 +8,1 @@ - {{{ - > ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn + ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn @@ -24,1 +18,0 @@ - }}} New description: ghc eqFn && ./eqFn Works fine and the program runs fine too, but a bit slow. Adding optimization (-O) makes ghc panic (even after setting a bigger 'tick' factor): ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for i386-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone f_XOO To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 700804 My program eqFn.hs: {{{ {-# LANGUAGE FlexibleInstances #-} instance Eq a => Eq (Bool -> a) where f == g = f True == g True && f False == g False nand a b = not (a && b) xor a b = nand (nand a c) (nand b c) where c=nand a b halfAdder a b = (xor a b, a && b) -- (sum, cOut) fullAdder cIn a b = let (s, c') = halfAdder a b (sum, c'') = halfAdder cIn s in (sum, c' || c'') adder2 cIn a0 b0 a1 b1 = let (o0, cTmp) = fullAdder cIn a0 b0 (o1, cOut) = fullAdder cTmp a1 b1 in (o0, o1, cOut) adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 = let (o0, o1, cTmp) = adder2 cIn a0 b0 a1 b1 (o2, o3, cOut) = adder2 cTmp a2 b2 a3 b3 in (o0, o1, o2, o3, cOut) adder8 cIn a0 b0 a1 b1 a2 b2 a3 b3 a4 b4 a5 b5 a6 b6 a7 b7 = let (o0, o1, o2, o3, cTmp) = adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 (o4, o5, o6, o7, cOut) = adder4 cTmp a4 b4 a5 b5 a6 b6 a7 b7 in (o0, o1, o2, o3, o4, o5, o6, o7, cOut) main = print (adder8 == adder8) }}} Btw, it works if I replace adder8 with adder4 in the last line. I think this is a bug because, if the problem is too complicated for the optimizer it should just skip that part instead of failing. -- Comment: If you actually want the inliner to work really hard for you then you can set the tick factor to 0. Just looking at the definition of `==` and `adder8` it is clear that very aggressive inlining will at some point create an exponentially big program. When `==` is inlined at the first step we get {{{ adder8 == adder8 = adder8 True == adder8 True && adder8 False == adder8 False = adder8 True True == adder8 True True && adder8 True False == adder8 True False && adder8 False True == adder8 False True && adder8 False False == adder8 False False = .... }}} There is little difference between the compiler taking a very long time (as it does in this example) and looping forever. Some kind of limit on the simplifier is prudent to stop the compiler appearing to hang. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 11:47:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 11:47:44 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.4d69bd7a0f35fe2e3298ec2dc94d1b2a@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 11:51:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 11:51:57 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.6fb31467b9ccfcc47ada28134d193913@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by 1chb): This is just a toy example. But what happens when I have a bigger program/system that contains one for the optimizer too heavy construct? Do I have to forget optimization for the rest of my program/system too? That is not practical. I think the optimizer should give up that part and optimize the rest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 12:13:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 12:13:18 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.c8b691330e6d3a301e34db3d6ab69b2b@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Perhaps the error type and error message should be changed here. "1chb" literally followed the suggestion to report a bug. {{{ ghc: panic! (the 'impossible' happened) ... Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 12:33:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 12:33:11 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.8b8d727544da77265ffb47280ae68b98@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by 1chb): Replying to [comment:2 mpickering]: > There is little difference between the compiler taking a very long time (as it does in this example) and looping forever. Some kind of limit on the simplifier is prudent to stop the compiler appearing to hang. This my toy example is not important. But what happens when I have a bigger program/system that contains one for the optimizer too heavy construct? Do I have to forget optimization for the rest of the program/system too? That is not practical. I think the optimizer should give up that part and optimize the rest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 12:37:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 12:37:14 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.190a3c0eefd3b30f37396583213eb37c@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by 1chb): Replying to [comment:5 j.waldmann]: > Perhaps the error type and error message should be changed here. > > "1chb" literally followed the suggestion to report a bug. > {{{ > ghc: panic! (the 'impossible' happened) Yes, actually not that impossible. > ... > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > Well, it is still a bug. Maybe explain that it is a known bug and need not be reported again. As a workaround, choose another compiler/language. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 12:57:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 12:57:47 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.0941fd0cca59a1d252f0947d081795d2@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): You can tell the compiler to not inline `==` by saying `{-# NOINLINE (==) #-}`. This causes the program to compile quickly. Reid reopened this ticket as he says (on IRC) that he doesn't expect the simplifier to behave like this without an `INLINE` pragma. He said he would reply here shortly. You example is quite interesting as the type class allows the compiler to repeatably inline `==` but at different types each time. Normal recursive definitions, even with a fixed input, are not unrolled but with the "recursion" happening in this way it is easier to trick the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 13:11:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 13:11:23 -0000 Subject: [GHC] #13209: ghc panic with optimization. In-Reply-To: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> References: <043.4aa915a41b6b44049e03436316772f8e@haskell.org> Message-ID: <058.4b637f6ac0a047899fe470598a0af685@haskell.org> #13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): The compiler does ( `./compiler/simplCore/Simplify.hs` ) {{{ completeCall ... = do case maybe_inline of Just .. -> do checkedTick ... Nothing -> ... }}} where `checkedTick` could raise the panic. It might be possible to check the tick counter, and take the `Nothing` branch if it's full. But do we want this? I guess it would prohibit *all* inlinings and rule applications from that point on (and until the end of the module?) which might produce really bad code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:21:21 -0000 Subject: [GHC] Batch modify: #11819, #12939 Message-ID: <20170130142121.07C673A2FF@ghc.haskell.org> Batch modification to #11819, #12939 by bgamari: milestone to None Comment: Ticket retargeted after milestone closed -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:24:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:24:46 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.498b03a4385391733c03053b72c4984f@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:32:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:32:17 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.370a38263d35baa28062306c3eb740a2@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.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): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:32:49 -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.1506ea1e74928c51c9697300c69cfdff@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => bgamari * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:33:45 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.68bdd85e3e951b78728f18412890a726@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | 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: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:34:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:34:07 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.935c221a01a129a0d182eae99176bb53@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"f60287c478a5f52bcb7e558c0995f552713772d1/ghc" f60287c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f60287c478a5f52bcb7e558c0995f552713772d1" Fix mismatched tick in GHC.Generics documentation [ci skip] A Generic derivation example in the documentation of GHC.Generics put a tick (used for datatype promotion) in the wrong place. Fixes #13206. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 14:35:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 14:35:21 -0000 Subject: [GHC] #13206: Error in GHC.Generics documentation In-Reply-To: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> References: <042.b9c2626c3be6df794ca3a2938cd535f9@haskell.org> Message-ID: <057.fa430190ae43982ff58295f707944113@haskell.org> #13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Ah, sharp eye! Thanks for the catch, I've since applied your fix in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 15:20:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 15:20:35 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows Message-ID: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's possible this is a duplicate of another runtime linker on Windows issue out there, but I'll post this just in case this really is a unique case. I was attempting to compile the `terminfo` library on Windows, and I actually made it surprisingly far--but I quickly stumbled when I actually tried to run some code in GHCi. First, make sure you have a native Windows version of `ncurses` installed. On MSYS2: {{{ $ pacman -S mingw-w64-x86_64-ncurses }}} And here's a stripped-down version of `terminfo`, which I'll use to demonstrate the bug: {{{#!hs module Main where import Control.Exception import Foreign import Foreign.C.String import Foreign.C.Types data TERMINAL newtype Terminal = Terminal (ForeignPtr TERMINAL) -- Use "unsafe" to make set_curterm faster since it's called quite a bit. foreign import ccall unsafe set_curterm :: Ptr TERMINAL -> IO (Ptr TERMINAL) foreign import ccall "&" del_curterm :: FunPtr (Ptr TERMINAL -> IO ()) foreign import ccall setupterm :: CString -> CInt -> Ptr CInt -> IO () setupTerm :: String -> IO Terminal setupTerm term = withCString term $ \c_term -> with 0 $ \ret_ptr -> do -- NOTE: I believe that for the way we use terminfo -- (i.e. custom output function) -- this parameter does not affect anything. let stdOutput = 1 -- Save the previous terminal to be restored after calling setupterm. old_term <- set_curterm nullPtr -- Call setupterm and check the return value. setupterm c_term stdOutput ret_ptr ret <- peek ret_ptr if (ret /=1) then throwIO $ SetupTermError $ "Couldn't look up terminfo entry " ++ show term else do cterm <- set_curterm old_term fmap Terminal $ newForeignPtr del_curterm cterm data SetupTermError = SetupTermError String instance Show SetupTermError where show (SetupTermError str) = "setupTerm: " ++ str instance Exception SetupTermError where main :: IO () main = do Terminal t <- setupTerm "xterm" print t }}} If you compile this code, it "works" (in the sense that it'll actually call the C code): {{{ $ ghc -lncursesw Terminfo.hs [1 of 1] Compiling Main ( Terminfo.hs, Terminfo.o ) Linking Terminfo.exe ... $ ./Terminfo Terminfo.exe: setupTerm: Couldn't look up terminfo entry "xterm" }}} But attempting to run the same code in GHCi is a disaster: {{{ $ runghc -lncursesw Terminfo.hs ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `nanosleep' ghc.exe: Could not on-demand load symbol '_nc_cookie_init' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_cookie_init' ghc.exe: Could not on-demand load symbol '.refptr._nc_wacs' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_wacs' ghc.exe: Could not on-demand load symbol '_nc_WIN_DRIVER' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_WIN_DRIVER' ghc.exe: Could not on-demand load symbol '_nc_get_driver' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_get_driver' ghc.exe: Could not on-demand load symbol '_nc_setupterm_ex' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_setupterm_ex' ghc.exe: Could not on-demand load symbol 'newterm' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `newterm' ghc.exe: Could not on-demand load symbol '.refptr._nc_globals' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_globals' ghc.exe: Could not on-demand load symbol '_nc_err_abort' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_err_abort' ghc.exe: Could not on-demand load symbol 'tparm' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `tparm' ghc.exe: Could not on-demand load symbol '.refptr._nc_prescreen' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_prescreen' ghc.exe: Could not on-demand load symbol '_nc_outch_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_outch_sp' ghc.exe: Could not on-demand load symbol '.refptr._nc_outch_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_outch_sp' ghc.exe: Could not on-demand load symbol '_nc_scrolln_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_scrolln_sp' ghc.exe: Could not on-demand load symbol '.refptr.SP' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr.SP' ghc.exe: Could not on-demand load symbol '.refptr.cur_term' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr.cur_term' ghc.exe: Could not on-demand load symbol '_nc_ospeed' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_ospeed' ghc.exe: Could not on-demand load symbol 'set_curterm' Terminfo.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: set_curterm This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} Also reproducible on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 16:20:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 16:20:44 -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.e024fac341512b77ac60c93ca7e9396f@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: | -------------------------------------+------------------------------------- Changes (by phadej): * status: new => patch * differential: => Phab:D3024 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:02:49 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.22c82fd5066d97ecfcca38c8060a7d8c@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Phab:D2983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7363d5380e600e2ef868a069d5df6857d9e5c17e/ghc" 7363d538/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7363d5380e600e2ef868a069d5df6857d9e5c17e" Check that a default type signature aligns with the non-default signature Before, GHC was extremely permissive about the form a default type signature could take on in a class declaration. Notably, it would accept garbage like this: class Monad m => MonadSupply m where fresh :: m Integer default fresh :: MonadTrans t => t m Integer fresh = lift fresh And then give an extremely confusing error message when you actually tried to declare an empty instance of MonadSupply. We now do extra validity checking of default type signatures to ensure that they align with their non-default type signature counterparts. That is, a default type signature is allowed to differ from the non-default one only in its context - they must otherwise be alpha-equivalent. Fixes #12918. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2983 GHC Trac Issues: #12918 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:02:49 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.ce6902b5c40806866cbc3b00a423a65a@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"559357384e300355b62edb3d60dcc3fadb942a50/ghc" 5593573/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="559357384e300355b62edb3d60dcc3fadb942a50" Fixes bug #11046 For some time now, type-level operators such as '+' have been treated as type constructors, rahter than type variables. This pathc fixes TH's `lookupName` function to account for this behavior. Reviewers: bgamari, austin, goldfire, RyanGlScott Reviewed By: RyanGlScott Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D3025 GHC Trac Issues: #11046 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:02:49 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.512ee947163ca81abab1fb22486fe26e@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | 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): Phab:D3010 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"91691117fc194c525f58ccd5b266dd1d10493e5a/ghc" 91691117/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91691117fc194c525f58ccd5b266dd1d10493e5a" Add a flag to emit error messages as JSON This patch adds the flag `-ddump-json` which dumps all the compiler output as a JSON array. This allows tooling to more easily parse GHC's output to display to users. The flag is currently experimental and will hopefully be refined for the next release. In particular I have avoided any changes which involve significant refactoring and provided what is easy given the current infrastructure. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: DanielG, gracjan, thomie Differential Revision: https://phabricator.haskell.org/D3010 GHC Trac Issues: #13190 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:02:49 -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.587a77b2877b6fb0fe9b5df33e506632@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 Ben Gamari ): In [changeset:"f41c27d3ffdddbb1afe07de1bd25205061194c93/ghc" f41c27d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f41c27d3ffdddbb1afe07de1bd25205061194c93" Slighly clean up symbol loading error. The symbol not found error that is triggered during lazy-loading was a bit chaotic before. This reformats it a bit to: ``` ghc-stage2.exe: | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev' ghc-stage2.exe: | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv' ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved. See top entry above. ``` I have also thought about also showing the demangled names, as it may be useful for the end user. `libgcc` seems to provide a method for this so we wouldn't need any extra dependency. Any thoughts on this or would it not be useful? Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3027 GHC Trac Issues: #13093, #13113 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:02:49 -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.93cc7b1d03d8239af21343b8044d2d5f@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 Ben Gamari ): In [changeset:"f41c27d3ffdddbb1afe07de1bd25205061194c93/ghc" f41c27d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f41c27d3ffdddbb1afe07de1bd25205061194c93" Slighly clean up symbol loading error. The symbol not found error that is triggered during lazy-loading was a bit chaotic before. This reformats it a bit to: ``` ghc-stage2.exe: | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev' ghc-stage2.exe: | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv' ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved. See top entry above. ``` I have also thought about also showing the demangled names, as it may be useful for the end user. `libgcc` seems to provide a method for this so we wouldn't need any extra dependency. Any thoughts on this or would it not be useful? Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3027 GHC Trac Issues: #13093, #13113 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:05:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:05:33 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double Message-ID: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compare {{{ rwbarton at morphism:~$ ghc-8.0.1 -e '-0.0' -0.0 rwbarton at morphism:~$ ghc-8.0.1 -XNegativeLiterals -e '-0.0' 0.0 }}} This behavior is logical, but unexpected. The logic is that with `NegativeLiterals` the literal `-0.0` means `fromRational ((-0)%0)`, which equals `fromRational 0`, which for `Double` is positive zero, not negative zero. But this seems unfortunate. Perhaps it would be best if `-0.0` (or `-` applied to any other literal mathematically equal to zero) was desugared as `negate 0.0` even under `NegativeLiterals`, since there doesn't seem to be any other reason to write `-0.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:12:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:12:27 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.fd16e8c4e0469367be74c853e9c96d09@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:12:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:12:38 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.ccd28cb9cf9978b6388def8cfb29e93d@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:13:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:13:11 -0000 Subject: [GHC] #13190: Add a flag to dump compiler output as JSON In-Reply-To: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> References: <049.5770443e67b845dfa8cb6d7be27fb2b3@haskell.org> Message-ID: <064.346ec8e76781f1f2b3bd072f590069f9@haskell.org> #13190: Add a flag to dump compiler output as JSON -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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:D3010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been implemented but the interface is still very much a work-in- progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 19:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 19:13:50 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.cee2e3a5c797f2aacc0d60189ecf1dbd@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Phab:D2983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 20:15:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 20:15:50 -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.a2ee7d48c2f60d0a2a11b01b82469fcc@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 int-e): Here's an attempt at a more reliable testcase: {{{ {-# LANGUAGE BangPatterns #-} import Control.Concurrent import Control.Monad import Control.Monad.ST.Lazy import Control.Exception import Data.STRef import Data.IORef import Control.Concurrent.MVar import Data.List -- evil ST action that tries to synchronize (by busy waiting on the -- shared STRef) with a concurrent evaluation evil :: ST s [Int] evil = do r <- strictToLazyST $ newSTRef 0 replicateM 100 $ do i <- strictToLazyST $ readSTRef r let !j = i + 1 strictToLazyST $ writeSTRef r j let go 0 = return () go n = do i' <- strictToLazyST $ readSTRef r when (j == i') $ go (n-1) go 100 return j main = do let res = runST evil s0 <- newIORef (map pred (0 : res)) s1 <- newIORef (map pred (1 : res)) m0 <- newMVar () m1 <- newMVar () forkIO $ do putMVar m0 () readIORef s0 >>= evaluate . foldl' (+) 0 putMVar m0 () forkIO $ do putMVar m1 () readIORef s1 >>= evaluate . foldl' (+) 0 putMVar m1 () threadDelay 10000 replicateM 3 $ takeMVar m0 >> takeMVar m1 v0 <- tail <$> readIORef s0 v1 <- tail <$> readIORef s1 print (v0 == v1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 21:02:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 21:02:26 -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.3e023100ca91b5de195559c80880435b@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"32729d3586d7ecdeb8561b6d0b2a688db709560c/ghc" 32729d35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32729d3586d7ecdeb8561b6d0b2a688db709560c" Turn libraries/integer-gmp/gmp/tarball into a submodule The submodule repository contains the latest version of the GMP source distribution (6.1.2) with the doc/ subdirectory removed, as described in gmp/ghc.mk. Rather than applying the old patch from gmp/tarball/patch I moved its contents into gmp/gmpsrc.patch, canceling a patch related to memory management there. Experimentally, the PIC-related patch for OS X is still necessary. The upgrade to GMP 6.1.2 fixes #7655. Test Plan: Built on OS X with in-tree gmp and tested that the command `ghc -e 'length (show (2^(5*10^6) :: Integer))'` no longer segfaults. Reviewers: mpickering, hvr, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D3044 GHC Trac Issues: #7655 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 21:30:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 21:30:11 -0000 Subject: [GHC] #13143: NOINLINE and worker/wrapper In-Reply-To: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> References: <046.37e4d572fbac449186e07670b515a2d3@haskell.org> Message-ID: <061.cc562eac8257cbac0ebce888cec3774a@haskell.org> #13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: 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): D3046 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => D3046 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 21:57:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 21:57:34 -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.7f089ed49b35ef1d23b32a569df727d3@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): No, it's not, will be done for 8.4. It's the same underlying reason. The `mingw` spec file for GCC adds `-lpthread` automatically in certain circumstances. In this case you can get it to work by just adding `-lpthread` manually to your link command. https://github.com/gcc- mirror/gcc/blob/master/gcc/config/i386/mingw32.h#L91 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 22:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 22:16:54 -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.32ccb7fea8c1cab31f9bf1587b3c38cd@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, adding `-lpthread` doesn't seem to work around the issue for me: {{{ $ ../../../Software/ghc/inplace/bin/runghc -lncursesw -lpthread Terminfo.hs GHC runtime linker: fatal error: I found a duplicate definition for symbol ungetch whilst processing object file C:\msys64\mingw64\lib\libncursesw.a The symbol was previously defined in (GHCi built-in symbols) This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: Could not on-demand load symbol 'ungetch_sp' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `ungetch_sp' ghc-stage2.exe: Could not on-demand load symbol 'set_escdelay_sp' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `set_escdelay_sp' ghc-stage2.exe: Could not on-demand load symbol 'newterm' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `newterm' ghc-stage2.exe: Could not on-demand load symbol '.refptr._nc_globals' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `.refptr._nc_globals' ghc-stage2.exe: Could not on-demand load symbol '_nc_err_abort' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `_nc_err_abort' ghc-stage2.exe: Could not on-demand load symbol 'tparm' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `tparm' ghc-stage2.exe: Could not on-demand load symbol '.refptr._nc_prescreen' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `.refptr._nc_prescreen' ghc-stage2.exe: Could not on-demand load symbol '_nc_outch_sp' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `_nc_outch_sp' ghc-stage2.exe: Could not on-demand load symbol '.refptr._nc_outch_sp' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `.refptr._nc_outch_sp' ghc-stage2.exe: Could not on-demand load symbol '_nc_scrolln_sp' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `_nc_scrolln_sp' ghc-stage2.exe: Could not on-demand load symbol '.refptr.SP' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `.refptr.SP' ghc-stage2.exe: Could not on-demand load symbol '.refptr.cur_term' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `.refptr.cur_term' ghc-stage2.exe: Could not on-demand load symbol '_nc_ospeed' ghc-stage2.exe: C:\msys64\mingw64\lib\libncursesw.a: unknown symbol `_nc_ospeed' ghc-stage2.exe: Could not on-demand load symbol 'set_curterm' Terminfo.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: set_curterm This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 22:26:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 22:26:49 -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.106a0e1297b84f7944a2465d18026837@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): That's a different error, now it found a duplicate symbol `ungetch`. Because we're re-exporting it from the RTS and apparently so is `libncursesw.a`. We should probably stop exporting these and add the library that contains them. Or add them as weak symbols. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 30 22:37:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jan 2017 22:37:58 -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.f086694498c6c501b897861ec6d77140@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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * priority: low => normal * status: infoneeded => upstream Comment: Windows has no problem with forward slashes in paths. See the note on https://msdn.microsoft.com/en- gb/library/windows/desktop/aa365247(v=vs.85).aspx My guess of what's going on is the cpphs is incorrectly handling fully qualified paths. It must be combining the search directories and file, and incorrectly handling the `.` case. You should report this to `cpphs` https://github.com/malcolmwallace/cpphs/issues The error is there and not GHC. Could you link back to here as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 01:40:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 01:40:50 -0000 Subject: [GHC] #13164: idle time full GCs (idle cpu usage) In-Reply-To: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> References: <048.9e890b7fce1df65473214dcb8b663966@haskell.org> Message-ID: <063.f086063ed09b4c82d54341e5c7b6a0c0@haskell.org> #13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: idle GC Operating System: 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): > How about we give the idle GC a time budget expressed as a % of wall clock time? This sounds sensible, e.g., if the idle GC last ran for m milliseconds, wait (at least) 100*m milliseconds before running it again. > Another thought: If there was an upper bound on the interval between full GCs (idle or not) you'd get reliable deadlock detection even with "forever threaddelay" cases. This makes sense, too. So the 100*m timer should be reset whenever we do a full GC. Then we probably no longer need the "idle" condition. (But when the RTS is ''truly'' idle then we should not do another GC, of course. For example, currently when you leave ghci idle in a terminal it does one idle GC after (GHC's custom idle GC time of) 5 seconds, but then doesn't do another GC after 5 more seconds if you haven't interacted with it at all.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 01:44:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 01:44:22 -0000 Subject: [GHC] #13201: Type-level naturals aren't instantiate with GHCi debugger In-Reply-To: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> References: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> Message-ID: <058.a86600200dee5da087fcc0251c801e01@haskell.org> #13201: Type-level naturals aren't instantiate 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I took a quick look at this, thinking the issue would be that, in `foos`, the information of the specific type `n` is unavailable at runtime. But apparently it's not so simple, since if you write an ordinary parametrically polymorphic function like {{{#!hs myFun :: [a] -> [a] myFun l = l ++ reverse l }}} and step into `myFun`, ghci is still capable of displaying the specific type of `l`. So, my conclusion is that how this works is a mystery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 05:11:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 05:11:33 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.58261c5d39625223046be90871fc9695@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 bgamari): Phab:D2504 adds limited support for `StaticPointers` in GHCi. While expressions entered at the REPL still cannot contain `static` expressions, modules loaded into the interpreter may. This should recover the majority of the convenience that one previously lost with `StaticPointers`. Note, however, that there is a bit of a memory leak as static expressions will necessarily never be unloaded, even after the module that introduced them goes out of scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 05:43:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 05:43:53 -0000 Subject: [GHC] #13201: Type-level naturals aren't instantiated with GHCi debugger (was: Type-level naturals aren't instantiate with GHCi debugger) In-Reply-To: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> References: <043.2d9b82fb9d4411fd0a29dd6e6365673f@haskell.org> Message-ID: <058.989be7f67935fd482bfdf50fa3562fd2@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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 08:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 08:26:23 -0000 Subject: [GHC] #12193: Include target versions of unlit and hsc2hs when cross-compiling In-Reply-To: <047.70c7f34a854dd4d3e899f2d863451090@haskell.org> References: <047.70c7f34a854dd4d3e899f2d863451090@haskell.org> Message-ID: <062.bc9589b4be985eaa2faf760ad1d692ac@haskell.org> #12193: Include target versions of unlit and hsc2hs when cross-compiling -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Build System | Version: 8.0.1 Resolution: | Keywords: cross-compile Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glaubitz): Please note, the same change must be introduced for ''hp2ps'' as well. See this bug report I just filed in Debian regarding cross-compilation [1]. It lists all the remaining tiny issues to resolve before cross- compiling GHC works out of the box. > [1] [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853285] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 14:08:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 14:08:40 -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.1508b33276f597a458f30fb51077bb82@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: 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 domenkozar): * cc: domen@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 14:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 14:46:15 -0000 Subject: [GHC] #13212: Support abs as a primitive operation on floating point numbers. Message-ID: <046.0fa5a9a408d7a4d76cfff2dd4c5e7b6b@haskell.org> #13212: Support abs as a primitive operation on floating point numbers. -------------------------------------+------------------------------------- Reporter: dominic | 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: -------------------------------------+------------------------------------- Haskell differs from C and FORTRAN on the manner in which it computes the absolute value of floating point numbers. Both FORTRAN and C support a `fabs` primitive function that is compiled directly to the underlying `fabs` machine instruction on either AMD64 or Intel x86 processors (with a small amount of stack manipulation). Haskell, however, does not support `abs` as a primitive operation on floating point numbers. Instead, Haskell desugars `abs` to the following: abs x | x == 0 = 0 -- handles (-0.0) | x > 0 = x | otherwise = negateFloat x Rather than calling the utilizing the `fabs` mnemonic or twiddling the sign bit, both of which can be executed in a single instruction, this implementation results in ~15 machine instructions and requires ~4-5 times the number of clock cycles to execute. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 15:16:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 15:16:46 -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.653a780ade369b781217870f0178ea6d@haskell.org> #13212: Support abs as a primitive operation on floating point numbers. -------------------------------------+------------------------------------- Reporter: dominic | Owner: 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => newcomer Comment: Yes, this would be worthwhile and not difficult. See https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp for the steps involved and https://phabricator.haskell.org/D1334 for a recent example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 15:23:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 15:23:34 -0000 Subject: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles In-Reply-To: <045.78bd18875d643372fae04b848faa0b90@haskell.org> References: <045.78bd18875d643372fae04b848faa0b90@haskell.org> Message-ID: <060.8e84bb78ab91c320493c9f92c0bbc1ff@haskell.org> #7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: floating | point Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9238, #13212 | Differential Rev(s): Phab:D145 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #9238 => #9238, #13212 Comment: Ticket for adding a faster `abs` implementation is #13212. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 15:24:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 15:24:25 -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.e4cc226080ada7632ff2d505ac449b0c@haskell.org> #13212: Support abs as a primitive operation on floating point numbers. -------------------------------------+------------------------------------- Reporter: dominic | Owner: 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 rwbarton): See also #7858, which fixed the definition of `abs` and `signum`. There it was suggested that a ticket be created for making the implementation more efficient, but as far as I can tell no one ever did so (until now). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:05:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:05:12 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.1e153716f5277eb82e0406ae9e6ca0f5@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here's a simple example of the quadratic code size I was talking about in comment:7, not specific to Read or Applicative or Monad. {{{#!hs f a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 = a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9 + a10 }}} At the Core and STG stages the size of `f` is linear in the number of arguments. But the Cmm for `f` builds a thunk for the first argument `a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9` and then calls `+`. In order to build that thunk it has to copy `a1` through `a9` into the thunk, as they are its free variables. Then the code for that thunk is going to build another thunk for `a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8`, which requires copying `a1` through `a8` again, and so on. The total code size, work done and allocations are all quadratic in the number of arguments. In this particular case it would clearly be better to do all the thunk construction up front in `f`, like (pseudo-STG) {{{#!hs f a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 = let t2 = a1 + a2 t3 = t2 + a3 t4 = t3 + a4 ... t9 = t8 + a9 in t9 + a10 }}} which would be linear code size, work and allocations in the number of arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:30:12 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.9a943bc06b5fe147c85a0119f17c695f@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): However, the quadratic behavior exhibited by the Read instance is more similar to this example {{{#!hs f :: (Int -> a) -> a f k = k 0 {-# NOINLINE f #-} v :: (Int,Int,Int,Int,Int,Int,Int,Int,Int,Int) v = f (\a1 -> f (\a2 -> f (\a3 -> f (\a4 -> f (\a5 -> f (\a6 -> f (\a7 -> f (\a8 -> f (\a9 -> f (\a10 -> (a1,a2,a3,a4,a5,a6,a7,a8,a9,a10))))))))))) }}} `v` is supposed to correspond to the desugaring of the long `do` blocks in slyfox's attachments. Here the quadratic blowup at the Cmm stage is caused by the fact that the free variables of the nth lambda are all the preceding `a1`, ..., `an`. We have to copy `a1` through `an` into the (n+1)st lambda that we provide as an argument to the next `f`. This is the blowup that I said I didn't know how to solve in the code generator in comment:7. However, (I claimed that) in this case we can avoid generating such nested lambdas in the first place by changing the desugaring to use Applicative methods rather than Monad ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:31:19 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.9ec2b0944493b4f9ef6177c5df7f6619@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): (In reply to comment:12) Is this a specific `+`, or just the overloaded method from `Num`? I guess the latter, as a strict `+` would yield quite different code. So you are proposing to add a transformation to STG (or Core) that replaces {{{ let t1 = let t2 = e1 in e2 in e3 }}} with {{{ let t2 = e1 t1 = e2 in e3 }}} Can we give an easy criterion when this transformation is beneficial? The problem is that this will increase allocation in the case when `t1` is not called, as it is more space efficient to pack the union of the free variables of `e1` and `e2` into one closure, instead of having one for the free variables of `e1` and one for those of `e2`. We could say “Do this transformation if the free variables of e2 and e1” are disjoint. Then we’d allocate two extra words (one for the info table of `t2`, and one pointer to that in the closure for `t1`), but have some nice gains if `t1` is indeed called. But this rule would not fire in this case, because the `Num a` dictionary is also a free variable, which would now have to be copied into both closures! I guess one could try and see whether real-world programs benefit from this transformation, and how many shared free variables between `e1` and `e2` are ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:41:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:41:13 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.ba9ad51626a9c80456ecc4d71eee921e@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:14 nomeata]: > (In reply to comment:12) Is this a specific `+`, or just the overloaded method from `Num`? I guess the latter, as a strict `+` would yield quite different code. Right, I meant the latter. It didn't occur to me that this behavior would only occur when `(+)` is not known by GHC to be strict; I thought it would be enough for GHC to have to perform the call to `(+)`, i.e., not inline it. > So you are proposing to add a transformation to STG (or Core) that replaces > {{{ > let t1 = let t2 = e1 > in e2 > in e3 > }}} > with > {{{ > let t2 = e1 > t1 = e2 > in e3 > }}} > > Can we give an easy criterion when this transformation is beneficial? > > The problem is that this will increase allocation in the case when `t1` is not called, as it is more space efficient to pack the union of the free variables of `e1` and `e2` into one closure, instead of having one for the free variables of `e1` and one for those of `e2`. And you're right that it's only a gain when `(+)` is actually going to evaluate `t1`, and a loss when it is not going to. In this case the gain is asymptotic and the loss is a constant factor, but if there were a lot of subexpressions and few free variables then the reverse could be true. > We could say “Do this transformation if the free variables of e2 and e1” are disjoint. Then we’d allocate two extra words (one for the info table of `t2`, and one pointer to that in the closure for `t1`), but have some nice gains if `t1` is indeed called. > > But this rule would not fire in this case, because the `Num a` dictionary is also a free variable, which would now have to be copied into both closures! > > I guess one could try and see whether real-world programs benefit from this transformation, and how many shared free variables between `e1` and `e2` are ok. Perhaps this discussion should move to a new ticket, since I remembered it is actually not the issue with the derived Read instance after all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:45:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:45:37 -0000 Subject: [GHC] #13213: Lifting thunks out of thunks to reduce their size. Message-ID: <046.1689ccc048c57b0152cdb9ec365a6ae5@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of this thread: ticket:10980#comment:12 The idea is to add a transformation to STG (or Core) that replaces {{{ let t1 = let t2 = e1 in e2 in e3 }}} with {{{ let t2 = e1 t1 = e2 in e3 }}} Can we give an easy criterion when this transformation is beneficial? The problem is that this will increase allocation in the case when `t1` is not called, as it is more space efficient to pack the union of the free variables of `e1` and `e2` into one closure, instead of having one for the free variables of `e1` and one for those of `e2`. We could say “Do this transformation if the free variables of `e2` and `e1`” are disjoint. Then we’d allocate two extra words (one for the info table of `t2`, and one pointer to that in the closure for `t1`), but have some nice gains if `t1` is indeed called. But this rule would not fire in the [ticket:10980#comment:12 original example], because the `Num a` dictionary is also a free variable, which would now have to be copied into both closures! I guess one could try and see whether real-world programs benefit from this transformation, and how many shared free variables between `e1` and `e2` are heuristically ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:47:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:47:23 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.a32063a556d060834c2be17e740d346c@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Perhaps this discussion should move to a new ticket, since I remembered it is actually not the issue with the derived Read instance after all? Sure, #13213 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:48:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:48:46 -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.75a4793e227173082c35f945974412f7@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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Copying the original example here for visibility, the issue (bug?) is that the (polymorphic in `Num`) function `f` defined by {{{#!hs f a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 = a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9 + a10 }}} has quadratic code size and allocations in the number of arguments (here 10). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 16:53:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 16:53:45 -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.2cb551daabdf671317fd0511eacf493d@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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Anecdotally it's fairly common to see ugly long strings of `mov` instructions in generated code, though I don't know whether they are from cases like this one, the similar but distinct case of ticket:10980#comment:13, or something completely different like record updates in a record with many fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 17:55:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 17:55:31 -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.c721e348f8491c493c2e2607a238933b@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: | -------------------------------+-------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I verified that HEAD still validates on OS X using the in-tree GMP, and that the bus error from `ghc -e 'length (show (2^(5*10^6) :: Integer))'` is gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 18:23:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 18:23:38 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.a8c9a7113953588c9687ca681137383c@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 bgamari): This is the sort of change that the proposal process was designed to consider. That being said, this particular change is fairly small in scope and it is quite late in the 8.2 cycle. If no one else objects I would be willing to forgo the proposal and merge Phab:D2822. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 18:38:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 18:38:18 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.c79f3e3a9bd280db0730e1664a4bd373@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 22:11:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 22:11:30 -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.654d4f3ba516e2871ef08ce5f506f733@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: | -------------------------------------+------------------------------------- Changes (by dominic): * owner: => dominic Comment: I am happy to give this a go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 22:50:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 22:50:27 -0000 Subject: [GHC] #13214: Orphan instances in Backpack signatures don't work Message-ID: <045.aaf4e6a8504aa919fdbb802a84ccc90e@haskell.org> #13214: Orphan instances in Backpack signatures don'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 instance Show (a -> b) module B where import A f = show (\x -> x) }}} There are probably other problems too but here's the start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:00:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:00:20 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.997ca1f74972b3a92a1ce7b4c6ed78f5@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 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:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"748b79741652028827b6225c36b8ab55d22bdeb0/ghc" 748b7974/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="748b79741652028827b6225c36b8ab55d22bdeb0" Use top-level instances to solve superclasses where possible This patch introduces a new flag `-fsolve-constant-dicts` which makes the constraint solver solve super class constraints with available dictionaries if possible. The flag is enabled by `-O1`. The motivation of this patch is that the compiler can produce more efficient code if the constraint solver used top-level instance declarations to solve constraints that are currently solved givens and their superclasses. In particular, as it currently stands, the compiler imposes a performance penalty on the common use-case where superclasses are bundled together for user convenience. The performance penalty applies to constraint synonyms as well. This example illustrates the issue: ``` {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-} module B where class M a b where m :: a -> b type C a b = (Num a, M a b) f :: C Int b => b -> Int -> Int f _ x = x + 1 ``` Output without the patch, notice that we get the instance for `Num Int` by using the class selector `p1`. ``` f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int f = \ (@ b_a1EB) ($d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) -> + @ Int (GHC.Classes.$p1(%,%) @ (Num Int) @ (M Int b_a1EB) $d(%,%)_a1EC) eta1_B1 B.f1 ``` Output with the patch, nicely optimised code! ``` f :: forall b. C Int b => b -> Int -> Int f = \ (@ b) _ _ (x_azg :: Int) -> case x_azg of { GHC.Types.I# x1_a1DP -> GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#) } ``` Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: mpickering, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2714 GHC Trac Issues: #12791, #5835 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:00:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:00:20 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.a715e426a9d6556a1d59ac17bb753569@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj 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: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"748b79741652028827b6225c36b8ab55d22bdeb0/ghc" 748b7974/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="748b79741652028827b6225c36b8ab55d22bdeb0" Use top-level instances to solve superclasses where possible This patch introduces a new flag `-fsolve-constant-dicts` which makes the constraint solver solve super class constraints with available dictionaries if possible. The flag is enabled by `-O1`. The motivation of this patch is that the compiler can produce more efficient code if the constraint solver used top-level instance declarations to solve constraints that are currently solved givens and their superclasses. In particular, as it currently stands, the compiler imposes a performance penalty on the common use-case where superclasses are bundled together for user convenience. The performance penalty applies to constraint synonyms as well. This example illustrates the issue: ``` {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-} module B where class M a b where m :: a -> b type C a b = (Num a, M a b) f :: C Int b => b -> Int -> Int f _ x = x + 1 ``` Output without the patch, notice that we get the instance for `Num Int` by using the class selector `p1`. ``` f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int f = \ (@ b_a1EB) ($d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) -> + @ Int (GHC.Classes.$p1(%,%) @ (Num Int) @ (M Int b_a1EB) $d(%,%)_a1EC) eta1_B1 B.f1 ``` Output with the patch, nicely optimised code! ``` f :: forall b. C Int b => b -> Int -> Int f = \ (@ b) _ _ (x_azg :: Int) -> case x_azg of { GHC.Types.I# x1_a1DP -> GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#) } ``` Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: mpickering, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2714 GHC Trac Issues: #12791, #5835 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:29:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:29:02 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.ae2b3c0cc62a1fc91f01be4b64ca0bf9@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj 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: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:29:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:29:06 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.20c18d56f41fe482819c91b275881e13@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:49:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:49:39 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.2bfcb64d24b003f8602318ed0f3d3cf5@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11444 Blocked By: | Blocking: Related Tickets: #13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"b3576ed22570364f917c620a3cd29709355e4d51/ghc" b3576ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b3576ed22570364f917c620a3cd29709355e4d51" Mark reallyUnsafePtrEquality# as can_fail As described in the note, floating `reallyUnsafePtrEquality#` out can make it much less precise. Marking it `can_fail` will prevent it from floating out, which I believe is particularly important in light of 5a9a1738023aeb742e537fb4a59c4aa8fecc1f8a, and should also help prevent let/app invariant failures as seen in #11444 and #13027. Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2987 GHC Trac Issues: #13027, #11444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:49:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:49:39 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.24f39eeb71d245775830904ff54ae539@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- Reporter: erikd | Owner: dfeuer 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: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"b3576ed22570364f917c620a3cd29709355e4d51/ghc" b3576ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b3576ed22570364f917c620a3cd29709355e4d51" Mark reallyUnsafePtrEquality# as can_fail As described in the note, floating `reallyUnsafePtrEquality#` out can make it much less precise. Marking it `can_fail` will prevent it from floating out, which I believe is particularly important in light of 5a9a1738023aeb742e537fb4a59c4aa8fecc1f8a, and should also help prevent let/app invariant failures as seen in #11444 and #13027. Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2987 GHC Trac Issues: #13027, #11444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:50:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:50:28 -0000 Subject: [GHC] #13198: incorrect links and file names in GHC user's guide In-Reply-To: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> References: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> Message-ID: <062.f0d1dc554999ea9afdf95a6273418432@haskell.org> #13198: incorrect links and file names in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: patch Priority: normal | Milestone: 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): Phab:D3035 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b15136afb84a5193aa385ae7c635026aed54cf3b/ghc" b15136a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b15136afb84a5193aa385ae7c635026aed54cf3b" user-guide: fix links and file names (fixes #13198) There are some incorrect links and file names in GHC user's guide. * docs/users_guide/glasgow_exts.rst - GHC/Base.lhs - GHC/List.lhs * docs/users_guide/ffi-chap.rst - :base-ref:`Foreign` - :base-ref:`Control.Concurrent` I fixed them. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3035 GHC Trac Issues: #13198 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:50:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:50:28 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.d22acec00f2eebd7ebe1e273e94f06d6@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D727 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"44f079f74869d8cb417e2dcc104517ae7f593e5f/ghc" 44f079f7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44f079f74869d8cb417e2dcc104517ae7f593e5f" FloatOut: Allow floating through breakpoint ticks I believe this is actually a completely valid thing to do, despite the arguments put forth in #10052. All that was missing was logic in SetLevels to correctly substitute the cloned binders into the breakpoint's free variable list. This is a prerequisite for enabling StaticPointer support in the interpreter. Test Plan: Validate Reviewers: austin, scpmw Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 31 23:59:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jan 2017 23:59:39 -0000 Subject: [GHC] #13198: incorrect links and file names in GHC user's guide In-Reply-To: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> References: <047.b3e5eb8404d533bbcf8238d365ebc874@haskell.org> Message-ID: <062.59eb8d0ece21264760585ef912086706@haskell.org> #13198: incorrect links and file names in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: closed Priority: normal | 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): Phab:D3035 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler